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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 



The present document specifies the stage two description of the Voice Group Call Service (VGCS) which allows speech 
conversation of a predefined group of service subscribers in half duplex mode on the radio link taking into account 
multiple subscribers involved in the group call per cell. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] Void. 

[la] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[2] 3GPP TS 42.068: "Voice Group Call Service (VGCS); Stage 1". 

[3] 3GPP TS 43.022: "Functions related to Mobile Station (MS) in idle mode". 

[4] 3GPP TS 23.067: "enhanced Multi-Level Precedence and Pre-emption service (eMLPP); Stage 2". 

[5] 3GPP TS 44.018: "Mobile radio interface layer 3 specification; Radio Resource Control Protocol", 

[6] 3GPP TS 45.008: "Radio subsystem link control". 

[7] 3GPP TS 24.008: "Mobile radio interface Layer 3 specification; Core network protocols; Stage 3". 

[8] ITU-T Recommendation E.164: "The international public telecommunication numbering plan". 

[9] 3GPP TS 42.009(Rel-4): "Security aspects". 

[10] 3GPP TS 43.020: "Security related network functions". 

[II] 3GPP TS 44.068: "Group Call Control (GCC) protocol". 

[12] 3GPP TS 22.083: "Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 1". 

[13] 3GPP TS 29.002: "Mobile Application Part (MAP) specification". 

[14] 3GPP TS 23.040: "Technical realization of the Short Message Service (SMS)". 

[15] 3GPP TS 24.01 1 : "Point-to-Point (PP) Short Message Service (SMS) support on mobile radio 

interface". 

[16] 3GPP TS 28.062: "Inband Tandem Free Operation (TFO) of Speech Codecs; Service Description; 

Stage 3". 

[17] 3GPP TS 23.236: "Intra-domain connection of Radio Access Network (RAN) nodes to multiple 

Core Network (CN) nodes". 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 8 ETSI TS 1 43 068 V9.2.0 (201 0-1 0) 

3 Definitions and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 42.068 and the following apply: 

group call anchor MSC: the MSC responsible for managing and maintaining a particular voice group call 
The group call anchor MSC is determined as the one controlling the cells of the group call area (see also group call 
relay MSC). For voice group call services where the group call area exceeds one MSC area, the group call anchor MSC 
is predefined in the network. 

Group Call Attributes (GCA): group call area, dispatcher identities, and the non-activity time which results in the 
release of the voice group call by the network 

group call relay MSC: the MSC controlling cells of a group call area which are not under control of the group call 
anchor MSC for those voice group call services where the group call area exceeds one MSC area 

Group Call Register (GCR): functionality in the network containing the group call attributes 

group call serving MSC: In a RANflex configuration the group call serving MSC of a location area is a group call 
anchor MSC or a group call relay MSC that controls the group call signalling for this location area. A location area 
within the pool area has a unique group call serving MSC. For a service subscriber located in this location area the 
visited MSC may be different from the location area's group call serving MSC. 

In a RANflex configuration all location areas within a BSC service area are assigned to the same group call serving 
MSC. 

group members: service subscribers entitled to belong to a particular group classified by a certain group identification 
(group ID) 

group mode dedicated channel: In this mode, a mobile station participating in an ongoing voice group call is allocated 
at least two dedicated channels, only one of them being a S ACCH 

notification: notifications are given on common control channels or dedicated channels in order to inform group 
members which are either in idle mode or in dedicated mode or participating in a voice group call or voice broadcast 
call on the existence of voice group calls 

Notification CHannel (NCH): common control channel on which the notifications are sent by the network (equivalent 
to a paging channel) 

originator-to-dispatcher information: information sent by the service subscriber originating a voice group call to the 
network during call setup for distribution to the dispatchers to be attached to the group call during call setup 

RANflex configuration: A network configuration that allows a location area to be served by multiple MSCs in parallel. 
For details see 3GPP TS 23.236 [17] 

voice group call channel: combined uplink/downlink to be allocated in a cell of the group call area for a particular 
voice group call 

The uplink can be used by the presently talking service subscriber only. All mobile stations of the listening service 
subscribers in one cell shall listen to the common downlink. 

voice group call member: any group member or dispatcher participating in an on going voice group call 

point-to-point short message: information that may be transferred between a mobile station and a Service Center 

time-critical application-specific data: application-specific data which shall be transferred within the time limitation 
specified in 3GPP TS 42.068. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 24.008 [7] apply. 

dedicated mode 
group receive mode 
group transmit mode 
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3.2 Abbreviations 

For the purpose of the present document, the abbreviations given in 3GPP TR 21.905 [la] and the following apply: 

AMR Adaptive Multi-Rate 

CC Country Code 

D-ATT Downlink Attach 

DA Downlink Attach 

DRX Discontinuous reception 

DTMF Dual Tone Multi Frequency 

EFR Enhanced Full Rate 

eMLPP enhanced Multi-Level Precedence and Pre-emption 

GCA Group Call Attributes 

GCR Group Call Register 

NCH Notification Channel 

NDC National Destination Code 

SN Subscriber Number 

UA Uplink Attach 

VBS Voice Broadcast Service 

VGCS Voice Group Call Service 



4 Main concepts 

4.1 Group definition 

Service subscribers can become group members on a PLMN wide basis to one or more groups pre-defined in the 
network by a corresponding group identification (group ID). The membership enables them to initiate or receive voice 
group calls associated with that group ID. Certain dispatchers connected to external networks also require the capability 
to initiate or receive voice group calls. 

In addition to subscriber details in the HLR, it is necessary for the mobile station to be aware of its group membership 
by storing details on the SIM/USIM. This is required because it shall respond to notification messages which include 
only the group ID (i.e. no IMSI or TMSI details). 

Having become a group member, each service subscriber can set to active state or deactive state the group ID or any 
one out of his several group IDs on the SIM/USIM. In active state the subscriber can initiate voice group calls to that 
group. When in deactive state the subscriber can not make voice group calls to the group and the mobile station ignores 
any notification for that group. 

If no NCH is defined in the cell, mobiles shall assume VGCS service is not available on that cell. 

4.2 Group conversations 
4.2.1 Group call initiation 

4.2.1 .1 Normal operation with successful outcome 

A group call area can be restricted to a single MSC area or can exceed one MSC area. In a RANflex configuration a 
group call area can be restricted to a single pool area or can exceed one pool area. 

A voice group call shall be initiated by a calling service subscriber by a related input function, e.g. via MMI, specifying 
the selected service and the group ID dialled or by a calling dispatcher by the MSISDN address (see subclause 9.2). As 
an option, the request of the calling service subscriber to set up a voice group call may specify information to be sent as 
originator-to-dispatcher information to the network; in this case the originator-to-dispatcher information is included in 
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the signalling for call setup from the mobile station to the network. It is the responsibility of the input function to ensure 
that the originator-to-dispatcher information has a correct format (in particular, an allowed length). 

As a further option, the request of the calling subscriber may indicate one of the following talker priorities, listed in 
ascending order of talker priority: 

- normal subscriber; 

- privileged subscriber; 

- emergency subscriber. 

A mobile station supporting the use of talker priorities shall check with the SIM/USIM whether the subscriber is 
allowed to use the requested talker priority for the respective group ID before signalling the talker priority to the 
network. 

On reception of a VGCS setup request with a talker priority different from "normal subscriber", the MSC shall check 
with the VLR whether the subscriber has a subscription to use this talker priority. If the subscriber is not allowed to use 
the requested talker priority, the MSC shall reduce the talker priority to a value the subscriber is allowed to use. In any 
case the talker priority used by the MSC shall be signalled back to the calling service subscriber in the Connect 
message. 

If a VGCS setup request with talker priority "emergency subscriber" is received by the network and the subscription 
check is successful, the network shall set the emergency mode for this voice group call. The emergency mode may be 
reset during the voice group call (see subclause 4.2.2.1). 

The MSC in which a voice group call is initiated obtains the group call attributes by requesting the Group Call Register 
(GCR, see clause 5). Without a RANflex configuration or in a RANflex configuration, if visited MSC and group call 
serving MSC are identical, the MSC performs a local GCR interrogation. 

The local GCR interrogation after call initiation also determines whether the MSC shall act as anchor or as relay MSC. 
If the MSC is not the anchor MSC then the call will be "forwarded" from the relay to the respective anchor MSC 
(information also delivered by GCR) and further "call-establishment" is done by the anchor MSC as described in the 
following. 

In a RANflex configuration the VMSC in which a voice group call is initiated may be different from the group call 
serving MSC of the voice group call initiating subscriber's location area. In this case the VMSC derives the identity of 
the group call serving MSC from the initiating subscriber's LAC and requests the group call anchor MSC address from 
the group call serving MSC's GCR by means of the SEND_GROUP_CALL_INFO MAP service. The call is then 
"forwarded" from the VMSC to the anchor MSC and further "call-establishment" is done by the anchor MSC as 
described in the following. 

When a calling service subscriber or calling dispatcher initiates a voice group call, one voice group call channel shall be 
established in each cell of the group call area and notifications for that call shall be sent in each of these cells. As an 
alternative, voice group call channels may only be established in cells in reaction to responses received from mobile 
stations on the notifications using notification response procedure. At the same time standard connections to dispatchers 
in the mobile network or in an external network shall be established. If originator-to-dispatcher information has been 
received in the signalling for call setup from the mobile station to the network and if the originating MSC supports 
processing of originator-to-dispatcher information, this information is transformed into user-to-user information and 
sent to the dispatchers as UUSl when setting up the standard connections. 

A voice group call channel shall consist of a combined uplink/downlink. The uplink will be used exclusively by the 
presently talking service subscriber. All mobile stations of the listening service subscribers in one cell shall only listen 
to the same common downlink. 

During call establishment there are different options for the network to allocate a speech channel for the calling service 
subscriber: 

In the first option, the calling service subscriber shall have its dedicated standard connection during call establishment 
and for the first period when he will be the talking service subscriber up to the time when the network decides that he 
shall join the voice group call channel. The mobile station of the calling service subscriber shall then go to the voice 
group call channel and the dedicated standard connection shall be released. 
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In the second option, the network shall allocate a dedicated signalling channel (e.g. SDCCH) to be used by the mobile 
station up to the time when the voice group call channel in the originating cell is established and the network decides 
that the mobile station shall join the voice group call channel. 

Only one voice group call channel shall be established in each cell for any given voice group call, although there may 
be a number of simultaneous voice group calls within the same cell. 

Destination service subscribers shall be notified on the voice group call in each cell. These voice group call notification 
messages shall be broadcast on the Notification CHannel (NCH). 

The notification messages use the group ID rather than individual TMSIs/IMSIs. If the length of the group ID is less 
than 8 decimal digits , then the group call area ID is used in order to enable a resolution in the case of overlapping group 
call areas. A service subscriber's mobile station needs to be able to recognise notification messages for those group IDs 
subscribed to and presently activated. 

The network may also send messages on appropriate voice group call channel FACCHs, in order to notify group call 
members who may participate in other voice group calls. In addition, also paging information messages for standard 
calls may be sent in order to inform group call members on actually paged point-to-point calls. 

Further the network may provide notification on the voice group call to service subscribers who have subscribed to the 
paged group ID and which are in dedicated mode. The process of broadcasting messages on NCHs is to be carried out 
throughout the call in order to provide the "late entry" facility whereby group members entering the area can join the 
call. 

If the emergency mode is set for a voice group call, the network shall include an emergency mode indication in the 
voice group call notification messages sent on the NCH, the group call channel FACCHs of all other ongoing voice 
group calls, voice broadcast calls, and the FACCHs associated with dedicated channels. 

On receiving notification of a voice group call a group call member's mobile station shall adjust to the nominated 
channel to receive the voice group call if this channel was described in the notification message and receive the 
information on the downlink. Whilst receiving, the mobile station shall not transmit on the uplink SACCH. This group 
receive mode is different to the normal idle mode or dedicated mode. If no channel description was provided in the 
notification message, the mobile station shall establish a dedicated connection by use of the notification response 
procedure in order to respond to the notification. The network may then provide the mobile station with a channel 
description for the voice group call. 

As a further mobile station option, the mobile station may read its paging subchannel in the current cell while in group 
receive mode or in group transmit mode in order to receive paging messages for mobile terminated calls. 

4.2.1 .2 Exceptional procedures 

Completion of links into congested cells where pre-emption did not occur is required. 

On receiving details of a voice group call the user may choose to move to the notified call or the mobile station may 
automatically move to the notified call if the new call is of higher priority than the existing call and automatic 
acceptance applies for this priority level. 

4.2.2 On-going group calls 

4.2.2.1 Normal operation with successful outcome 

Within each voice group call starting from the instant where the calling service subscriber first becomes a listening 
service subscriber, one service subscriber has the access at any one time to the uplink of the voice group call channel 
and his speech is then broadcast on all voice group call channel downlinks accordingly. The mobile station of the 
talking service subscriber who uses the uplink of the voice group call channel can be commanded by the network to 
mute or unmute the downlink of the voice group channel when needed. The mobile station is commanded: 

to mute the downlink in order to avoid non intelligible echoes (in this case, the talking service subscriber can 
not hear dispatcher's voice); and 

to unmute the downlink in order to hear dispatcher's voice . 
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DTMF shall be used by dispatchers to trigger network signalling to mute and un-mute the downlink of a talking service 
subscriber as described in subclause 11.3.7.2. 

If more than one service subscriber applies for the uplink, contention resolution shall be performed in the network. 
Contention resolution shall be performed in the group call anchor MSC. 

Additionally, in order to speed up the uplink access procedure, the BSS may grant the uplink prior to contention 
resolution being performed by the group call anchor MSC. This would mean that more than one service subscriber may 
access to the uplink and the respective speech may be combined in the group call bridge and broadcast onto all voice 
group call downlink channels during a transitional period. The anchor MSC shall then select one of the talking 
subscribers and pre-empt the uplink use of the other talking subscribers. 

Dispatchers' voice involved shall be broadcast on the voice group call channel downlink at any time. Mobile 
dispatchers are provided with a standard link and thus with a dedicated permanent uplink different from the voice group 
call channel. 

All non-dispatcher group call members are provided with an indication on the voice group call channel of whether the 
uplink is in use. If a network supports the use of talker priorities, it shall indicate the talker priority of the current talking 
service subscriber together with this uplink busy indication, and repeat the uplink busy indication periodically. When 
the uplink is not in use, any non-dispatcher group call member can request access to the uplink. Any speech from 
dispatchers is combined with any speech from a talking service subscriber. 

The talker priorities specified in subclause 4.2.1.1 can be included by the mobile station in the uplink access message or 
priority uplink request message and used by the network to prioritize between different uplink requests or between an 
uplink request and the priority of the current talker. A mobile station shall not include a talker priority different from 
"normal subscriber" in the uplink access message and shall not send a priority uplink request message, if the network 
has indicated in the uplink busy message that talker priorities are not supported. 

An uplink request with talker priority "normal subscriber" is signalled as an uplink request without talker priority. 

If a subscriber requests for the uplink while the uplink is in use, a mobile station supporting the use of talker priorities 
shall signal the request to the network only if: 

- the subscriber is allowed to use the requested talker priority for the respective group ID; 

- the network supports the use of talker priorities. The mobile station shall assume that the network supports talker 
priorities, until the mobile station receives an uplink busy indication containing no talker priority information; 
and 

- the requested talker priority is higher than the talker priority of the current talking service subscriber. The mobile 
station shall consider the talker priority of the current talking service subscriber to be "normal subscriber", until 
it receives an uplink busy indication indicating the actual talker priority. 

If the BSS receives an uplink access message with a talker priority different from "normal subscriber", a BSS 
supporting the use of talker priorities shall delay the sending of the uplink request message to the MSC, until the MS 
identity, IMSI or TMSI, is received from the MS with the subsequent layer 3 message talker indication. The BSS shall 
then include in the uplink request message the layer 3 message, the requested talker priority, and the cell identity of the 
cell where the uplink access message was received. 

If the BSS receives a layer 3 message priority uplink request, it shall include the MS identity received from the MS in 
the uplink request message. The BSS shall also include, in the uplink request message, the requested talker priority and 
the cell identity of the cell where the priority uplink request message was received. 

The BSS shall send the uplink request message to the MSC only if the uplink is free or if the talker priority included in 
the uplink access is higher than the talker priority of the current talking service subscriber. If the layer 3 message is 
transmitted in the uplink request message, the BSS may omit the sending of the uplink request confirm message. 

In a RANflex configuration, if the group call serving MSC receives an uplink request message it shall check by 
analysing the NRI of the requesting subscriber's TMSI whether it is the requesting subscriber's VMSC. If it is not, the 
group call serving MSC shall retrieve the IMSI and information about subscribed talker priorities from the VLR of the 
VMSC by means of the MAP service SEND_GROUP_CALL_INFO. During this MAP operation the VMSC shall 
check the subscription for the group ID. 

In any configuration, if the MSC receives a talker request with a talker priority different from "normal subscriber" from 
the BSS, the MSC shall check whether the subscriber has a subscription to use this priority: 
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- if the subscriber is allowed to use the requested priority, the network shall disconnect the uplink allocated to the 
current talking service subscriber and assign the uplink to the requesting service subscriber; 

- otherwise, the network shall reject the uplink request with cause value "requested option not authorized". 

If a talker request with talker priority "emergency subscriber" is received from a subscriber who has a subscription to 
use this priority, the network shall additionally set the emergency mode and signal the emergency mode indication 

to the listeners of the group call, and 

to the other group members in the group call area with the group ID active, regardless whether they are in idle 
mode or dedicated mode, or participate in a different group call, 

until the emergency mode is reset by a subscriber with a specific subscription to do this. If the uplink is busy then the 
indication to the listeners shall be given periodically every Tl seconds. The emergency mode indication has no 
influence on the talker priority handling. 

If a subscriber requests to reset of the emergency mode, a mobile station supporting the use of talker priorities shall 
send an uplink access message or priority uplink request message indicating "emergency mode reset request" only if 

- the subscriber has a subscription for this request for the respective group ID; and 

- the network indicates that the emergency mode is set. 

If the BSS receives an uplink access message with an "emergency mode reset request", a BSS supporting the use of 
talker priorities shall wait until the MS provides the MS identity, IMSI or TMSI, with the subsequent layer 3 message 
talker indication. Then the BSS shall send an emergency reset indication to the MSC including the layer 3 message and 
the cell identity of the cell where the uplink access message was received. 

If the BSS receives a layer 3 message priority uplink request, it shall include the MS identity received from the MS in 
the emergency reset indication. The BSS shall also include, in the emergency reset indication message, the cell identity 
of the cell where the priority uplink request message was received. 

If the MSC receives an emergency reset indication from the BSS, the MSC shall check whether the subscriber has a 
subscription for this request. If so, the network shall: 

- stop sending the emergency mode indication; and 

set the talker priority to "normal subscriber", if the uplink status is uplink busy with talker priority "emergency 
subscriber" . 

If the subscriber has no subscription for the request or if the emergency mode is not set, then the MSC shall discard the 
request. 

The receipt of an "emergency mode reset request" does not trigger a talker change. 

If more than one service subscriber applies for the uplink, the one with the highest talker priority shall be accepted. An 
uplink access message or priority uplink request message with an "emergency mode reset request" shall be treated with 
higher priority than any uplink request with talker priority "normal subscriber", "privileged subscriber" or "emergency 
subscriber" . If several requests with the same highest priority are received, contention resolution between these requests 
shall be performed in the network. For the ranking of uplink access messages by the BSC, if the network additionally 
supports the transfer of time-critical application- specific data, see subclause 4.2.8.2.2 a. 

Contention resolution shall be performed by the BSC, relay MSC or anchor MSC which is the first to detect that more 
than one request with the same highest priority was received. An MSC performing contention resolution shall select the 
service subscriber whose request was received first by the MSC and pre-empt the uplink use of the other service 
subscribers. For contention resolution performed by the BSC see subclause 11.3.7.1. 

Mobile stations shall support the reception of additional information related to the current talking service subscriber. 
The transmission of additional information is optional for the network. If additional information is provided, then it is 
periodically repeated by the network as long as the current talking service subscriber keeps the uplink. The additional 
information consists of a string of up to 17 octets and is stored in the HLR as part of the subscription data of the 
subscriber. The contents and the encoding of the additional information is operator specific. 

The release of the uplink is triggered by the user and indicated by the mobile station to the network. The network shall 
then indicate to the listening mobile stations that the uplink is free. 
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Mobile stations in group receive mode use the group receive mode procedure (see 3GPP TS 43.022) to "camp-on" in a 
new cell to be able to listen to the group call channel. The mobile station may find the voice group call channel details 
of a new cell on the related NCH. 

A network may decide not to establish voice group call channels in all cells. Instead, notifications containing no channel 
description may be provided. If a mobile station moves to such a cell, it must establish a dedicated connection and 
respond to the notification by use of the notification response procedure in order to receive the voice group call. The 
network may then establish a voice group call channel and inform the mobile station on the channel position. 

If the uplink reply procedure is applicable for the voice group call, the network may obtain knowledge on whether 
mobile stations are listening in a cell by sending an uplink access request (perform uplink reply procedure) in an uplink 
free message on the voice group call channel downlink when no talking service subscriber is present in the cell. Mobile 
stations receiving such a request shall use uplink reply procedure and send uplink access bursts on the voice group call 
channel uplink with the establishment cause "reply on uplink access request". If no uplink access bursts are received by 
the network, the network may decide to release the voice group call channel in that cell and then provide notifications 
containing no channel description. 

NOTE: Concerning security aspects, whilst authentication and membership checking of mobile call originators 
and of mobile uplink users can be carried out, it is not possible to authenticate service subscribers in 
group receive mode if they have not before established a dedicated connection to respond to a 
notification. No equivalent of a group "TMSI" is provided to protect the "identity" of established voice 
group calls. 

The network may decide to reconfigure an existing voice group call's physical channel configuration, frequencies 
and/or hopping sequences as well as the cell channel description. For the cell in which the group call is being 
reconfigured, the network informs any listeners in group receive mode and any talker in group transmit mode of the 
change in VGCS channel description by using the VGCS reconfiguration procedure (see 3GPP TS 44.018 [5]). Mobile 
stations on receipt of the VBSA^GCS reconfiguration messages shall remain on the existing group channel until 
indicated starting time and then apply the new configuration to the VGCS call that the mobile station is currently 
involved in. 

4.2.2.2 Exceptional procedures 

When a talking subscriber's mobile station loses contact with the network, the network must detect this loss and set the 
uplink free so that other mobile stations may access the uplink. The talking subscriber's mobile station which has lost 
the contact with the network shall return immediately to the group receive mode. 

If a mobile station in group receive mode indicates a failure due to radio link time-out, the mobile station shall behave 
as specified in 3GPP TS 45.008 and go back to idle mode, possibly in another cell, as determined by the cell re- 
selection algorithm. If a notification is received for the same call, the mobile station shall try to reconnect. 

4.2.3 Leaving of a group call without termination 

A service subscriber can leave the voice group call at any point by "deselecting" it via an MMI function. Having 
deselected the voice group call the mobile station returns to idle mode and "ignores" any further notification messages 
related to that voice group call. 

NOTE: If a service subscriber does not wish to participate in calls to a particular group ID for long periods of 
time, the group ID shall be switched to deactive state by the subscriber. 

The service subscriber shall have the capability to reselect the voice group call. The mobile station shall not ignore 
notification messages to that call any more. 

The dispatcher shall be able to leave a voice group call without terminating it. 



4.2.4 Group call termination 



A voice group call can only be terminated by the calling service subscriber, by calling dispatcher, by an entitled 
dispatcher or due to no activity timer expiry (see subclauses 8.1.2.3 and 11.3.2.3). 
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The calling service subscriber can terminate the call only if he has access to the uplink. He shall remain the calling 
service subscriber during the length of the particular voice group call even if he leaves the call and then returns to it 
later. 

An entitled dispatcher can terminate the call at any time by using a network defined user operation (via DTMF). 

4.2.5 Acknowledgements 

The acknowledgement is an application option. 

For voice group calls which are identified by an acknowledgement flag mobile stations which have acknowledgement 
facilities have to return an acknowledgement message with a predefined content in a predefined manner. 

The acknowledgement shall be sent using an appropriate data service, to a predefined address or with a predefined short 
code stored on the SIM/USIM card. The network may apply geographical routing to a predefined acknowledgement 
service centre. 

4.2.6 Transactions between the mobile station and the network 

Mobile stations which are in group receive mode may support the reception of short messages to voice group calls, but 
shall not perform any other transactions with the network while adjusted to the voice group call channel. They shall 
leave the group receive mode and act in a standard way to perform any transaction if necessary and return to the voice 
group call afterwards. 

Mobile stations which have access to the voice group call channel uplink shall not perform any transactions for 
supplementary services, but may support the transmission and reception of short messages as specified in subclause 
11.3.9. 

4.2.7 Processing of originator-to-dispatcher information 

The calling service subscriber may include originator-to-dispatcher information during call setup. If the originating 
MSC supports processing of originator-to-dispatcher information, it transforms the received originator-to-dispatcher 
information into UUS 1 , and sends it: 

- if the originating MSC is not the voice group call anchor MSC: to the voice group call anchor MSC; 

- if the originating MSC is the voice group call anchor MSC: to the dispatchers to be attached to the group call 
during call setup of the connections to these dispatchers. 

The anchor MSC receiving UUS 1 in a voice group call setup from an originating relay MSC forwards this UUS 1 to the 
dispatchers to be attached to the group call during call setup of the connections to these dispatchers. 

Transformation of originator-to-dispatcher information: Originator-to-dispatcher information can be compressed or 
uncompressed. 

- Decompression of compressed originator-to-dispatcher information is specified in 3GPP TS 44.068. 

- The transformation of uncompressed originator-to-dispatcher information into UUS 1 is the UUS 1 containing the 
same user-user IE as the originator-to-dispatcher information. 

The transformation of compressed originator-to-dispatcher information into UUS 1 is the UUS 1 resulting from 
transforming the decompressed originator-to-dispatcher information into UUS 1 . 

4.2.8 Transfer of application-specific data to group call members 
4.2.8.1 General 

Mobile stations may support the transmission of application- specific data to other group call members or VGCS 
applications in the network, and the reception of application-specific data from other group call members or VGCS 
applications in the network during an ongoing voice group call, in parallel to the voice conversation. 

Service subscribers can request the transmission of application- specific data while they are talker or listener. 
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Editor's note: The transmission and reception of application- specific data by dispatchers is ffs. 

A mobile station supporting the transmission of application- specific data shall check with the USIM whether the 
subscriber is allowed to transmit application-specific data for the respective group ID before starting the signalling 
procedures specified in subsclause 4.2.8. 

The procedure specified in the following subclauses supports the transfer of application-specific data. 

The same procedure can also be used by the receiver of application-specific data to confirm the reception of 
application-specific data. 

NOTE: For the exact upper limit of application- specific data that can be sent in a single transmission see 

3GPP TS 44.018 [5]. The upper limit will be chosen so that the application-specific data together with the 
necessary control information fit into a single SABM frame. 

The support of the transfer of application-specific data by the network is an operator option. 

The exact format of the application- specific data is out of scope of the 3GPP specifications. If roaming service 
subscribers from other PLMNs are to be the supported or if a group call area includes cells from more than one PLMN, 
the use of application-specific data requires coordination between the operators. 

4.2.8.2 Sending of application-specific data 

4.2.8.2.1 By the talking service subscriber 

When application-specific data is to be sent and the talking subscriber is allowed to transmit application- specific data 
for the respective group ID, the mobile station of the talking service subscriber shall send a DATA INDICATION 
(Application_Data) message to the network on the uplink of the dedicated channel or group call channel. On receipt of 
the application-specific data, the network shall transmit these data to the other group call members as specified in 
subclause 4.2.8.4. 

NOTE: If the talker has to release the uplink before sending application- specific data, the MS follows the 
procedures specified in subclause 4.2.8.2.2. 

4.2.8.2.2 By a listener 

When application-specific data is to be sent and the network indicates the uplink as free, the listener shall use the group 
call channel uplink for the signalling as specified in item a) below. 

Otherwise, when the network does not indicate the uplink as free, the channel to be used by the listener is indicated by 
the network in the "uplink access indication" IE sent in periodic transmissions of the UPLINK BUSY message. If the 
talking service subscriber uses the group call channel uplink in the current cell, the RACH shall be used, see item b) 
below; otherwise the group call channel uplink shall be used, see item a) below. 

a) Sending application-specific data via the group call channel uplink 

When application-specific data is to be sent and the listener is allowed to transmit application- specific data for the 
respective group ID, the mobile station of the listener shall send an UPLINK ACCESS message with an appropriate 
establishment cause ("UL request for sending application- specific data") on the group call channel uplink to the BSS. 

It is an operator option whether the BSS treats an UPLINK ACCESS message with establishment cause "UL request for 
sending application- specific data" with higher or lower priority than UPLINK ACCESS messages with any other 
establishment cause. The same order of priorities applies to all voice group calls in a network. If the BSS grants the 
upHnk of the group call channel, then the MS sends a SABM (DATA INDICATION) message with its mobile identity 
and the application data to the network. The serving BSS responds with a UA (DATA INDICATION) message and 
releases the group call channel uplink. The MS returns to group receive mode. 

On receipt of the DATA INDICATION message, the BSC shall add the cell identifier of the cell where the application 
data were sent from and passes the L3 information by sending the UPLINK APPLICATION DATA message to the 
MSC. 

On receipt the UPLINK APPLICATION DATA message, the MSC shall distribute the data to all members of the group 
call (see subclause 4.2.8.4). 
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NOTE 1: Procedure a) is used to achieve the transfer time target for time-critical data. If all MSCs and BSCs 
involved in the voice group call support the feature "talker channel parameter", the "talker channel 
parameter" can be used to ensure that the voice group call channel uplink is available for the uplink 
access and the transmission of time-critical application-specific data. 

NOTE 2: In a network that is intended to support the transfer of time-critical data, the BSS will usually be 

configured to treat an uplink request for sending application-specific data with higher priority than any 
other uplink requests. 

b) Sending application-specific data via the RACH 

When application-specific data is to be sent and the listener is allowed to transmit application- specific data for the 
respective group ID, the mobile station of the listener shall leave the group call and send a CHANNEL REQUEST 
message with an appropriate establishment cause on the RACH to the BSS in order to request an SDCCH. When a new 
layer 2 connection is established on a SDCCH channel the data can be sent by the mobile station to the network with the 
DATA INDICATION 2 message on the main DCCH (figure 7j). 

In order to indicate to the network which group call the application-specific data is addressed to, the DATA 
INDICATION 2 message shall include the group call reference. 

On receipt of the DATA INDICATION 2 message the BSC shall add the cell identifier of the cell from which the 
application data was sent and pass the L3 information in the UPLINK APPLICATION DATA message to the MSC. 

On receipt of the UPLINK APPLICATION DATA message, the MSC shall distribute the data to all members of the 
group call (see subclause 4.2.8.4). 

4.2.8.3 Sending a confirmation of receipt of application-specific data 

On receiving application-specific data, any service subscriber can send a confirmation to the network which will send 
the confirmation to the ongoing group call. 

For the purpose of identifying the received data, the confirmation shall include the data_id which was received in the 
message that contained the application data that is being confirmed. 

The further proceeding is as described in 4.2.8.2.1 and 4.2.8.2.2 (see also figure 7i). 

4.2.8.4 Distributing application-specific data to a voice group call 
4.2.8.4.1 Distribution via the MSC 

On receipt of the UPLINK APPLICATION DATA, the MSC shall check if the sending subscriber has a subscription to 
the group ID. If yes, the MSC shall distribute the application-specific data dependent on the distribution parameter 
included in the DATA INDICATION or DATA INDICATION 2 message; otherwise the MSC shall discard the 
UPLINK APPLICATION DATA message. 

If the application-specific data are to be sent to the listeners and the talking service subscriber, the MSC shall proceed as 
follows: 

If the MSC is the anchor MSC, it shall put the application data and optionally the mobile subscriber's MSISDN into the 
BSSMAP message NOTIFICATION DATA and distribute the message towards all relay MSCs and all BSSs in its 
MSC area involved in the group call (figure 7f). If the MSC receives an indication from the originating BSC that the 
application-specific data were immediately distributed to the originating BSS area (see subclause 4.2.8.4.2), the MSC 
shall not send the BSSMAP message NOTIFICATION DATA to the originating BSS. 

If the MSC is a relay MSC, it shall put the application data and optionally the mobile subscriber's MSISDN into the 
BSSMAP message NOTIFICATION DATA and distribute the message to the anchor MSC and all BSSs of the relay 
MSC area. If the MSC receives an indication from the originating BSC that the application-specific data were 
immediately distributed to the originating BSS area (see subclause 4.2.8.4.2), the MSC shall not send the BSSMAP 
message NOTIFICATION DATA to the originating BSS. On receiving the NOTIFICATION DATA message from the 
relay MSC, the anchor MSC shall send the message towards all BSSs in its MSC area involved in the group call and to 
all relay MSCs except the relay MSC from which the NOTIFICATION DATA was received (figure 7h). The BSS shall 
broadcast the notification data to all listeners and talking service subscriber in the NOTIFICATION APPLICATION 
DATA message on the FACCH. 
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The network may repeat the NOTIFY APPLICATION DATA message for appHcation- specific data on the group call 
channel downlink. If a mobile station receives the NOTIFY APPLICATION DATA message more than once, it shall 
deliver only the first received message to its local application and discard any received repetitions of the message. 

The mechanism how the mobile station detects a repetition of the NOTIFY APPLICATION DATA message is 
application- specific. 

Editor's note: The sending of application-specific data to other destinations (e.g. dispatchers or applications) is ffs. 

4.2.8.4.2 Immediate distribution by the BSC 

As a network option, on receipt of application-specific data from the MS, the BSS may distribute the application- 
specific data immediately to the cells within the BSC area belonging to the group call area, if the distribution parameter 
included in the DATA INDICATION message or DATA INDICATION 2 message indicates that the appHcation- 
specific data are to be sent to the service subscribers. In addition, the BSC shall send the application-specific data to the 
MSC with an indication that the application-specific data were already distributed to the originating BSC area. 

When this network option is used, the BSS cannot include the mobile subscriber's MSISDN in the NOTIFY 
APPLICATION DATA message broadcast immediately to the cells within the BSC area. Furthermore, the BSS cannot 
check if the sending subscriber has a subscription for the group ID. 

If the network option of immediate distribution of application- specific data by the BSS is activated, then during the 
establishment phase of the voice group call the BSC shall store the cell identities of the cells belonging to the group call 
area and served by the BSC. 

NOTE: If this option is activated no subscription check by the MSC is possible. It is also not possible to include 
the mobile subscriber's MSISDN in the NOTIFY APPLICATION DATA message. 



5 General architecture 

5.1 Group Gall Register (GCR) 

The general architecture of GSM is maintained. In addition, a network function is required which is used for registration 
of the group call attributes, the Group Call Register (GCR). 

The GCR function is mainly a database function, holding information about voice group calls. 

NOTE 1 : The GCR implementation is not specified. It may be realized e.g. as a new network node, in a PABX 

directly attached to an MSC, inside an MSC or as an HLR. The interface between the GCR function and 
other functions is not specified in the GSM technical specifications. As a consequence, the functional split 
between MSC and GCR as developed in the present document is only indicative, and other functional 
splits can be implemented. 

The GCR data for a specific voice group call is set at the creation of the group call attributes, and can be subsequently 
modified. No support for these functions is specified in the GSM technical specifications. 
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Figure 1 : Functional architecture with a Group Call Register 

The signalling between the entities shown in figure 1 , for the two cases of service subscriber and dispatcher originated 
calls, shall be as defined in the following. 

Service subscriber originated: The service subscriber's VMSC shall perform subscription checking against VLR 
records. In a RANflex configuration it shall then derive from the service subscriber's current location area the group call 
serving MSC which may be different from the VMSC. 

Without a RANflex configuration or in a RANflex configuration, if the VMSC is the group call serving MSC, the 
VMSC shall consult its GCR to determine the group call attributes related to its MSC area and whether it is the group 
call anchor MSC for that voice group call. If it is not, the GCR shall provide with the group call attributes the routing 
information identifying the group call anchor MSC to the originating MSC. The originating MSC shall then route the 
voice group call to the anchor MSC. 

In a RANflex configuration, if the VMSC is not the group call serving MSC, the VMSC shall consult the group call 
serving MSC's GCR by means of the MAP service SEND_GROUP_CALL_INFO and retrieve the group call anchor 
MSC address. The originating MSC shall then route the voice group call to the anchor MSC. 

If the initiation of the voice group call had specified originator-to-dispatcher information and processing of originator- 
to-dispatcher information is supported by the originating MSC, the originator-to-dispatcher information is transformed 
by the originating MSC into UUSl and sent to the anchor MSC. If the originating MSC is the group call anchor MSC, 
along with the group call attributes, the GCR shall provide information on all group call relay MSCs to be involved. 

The group call anchor MSC shall set up links to all group call relay MSCs. It shall also initiate setup of point-to-point 
connections to the dispatchers associated to the voice group call (see subclause 8.1.2.2); if UUSl information has been 
received in the signalling for call setup from the originating MSC, this UUSl information is included in the setup of 
point-to-point connections to the dispatchers. Each MSC involved in a voice group call obtains its proper group call 
attributes from the GCR related to the MSC. 

The IMSI of the calling service subscriber must be provided to and stored in the anchor MSC and each relay MSC in 
order to allow the calling service subscriber to clear the group call later on. 

Dispatcher originated: In the case of dispatchers calling from an external network, the call request, in the form of an 
ISDN number, shall be received at a GMSC. The number shall be analysed and the call shall be directly routed to the 
group call anchor MSC by the GMSC based on the called identity without requesting an HLR. The group call anchor 
MSC shall interrogate the GCR and obtain the group call attributes. If an identical voice group call is currently in 
progress, the dispatcher shall be connected to this call and no new call shall be initiated. When interrogating the GCR, 
the identity of the calling dispatcher is compared with the list of dispatchers which are allowed to initiate the call. If the 
dispatcher is not in the list, or an identity is not provided, the network shall reject the call. 

NOTE 2: Optionally dispatchers may also be user of the GSM network in which the VGCS service is provided or 
may directly be connected to a PABX containing the GCR. Dispatcher which are registered for a certain 
voice group call and which have also a subscription for VGCS with the same group ID as the voice group 
call for which they are dispatcher shall deactivate this group ID when they are located in the 
corresponding group call area in order to avoid conflicts between paging for the dispatcher and 
notifications for the group ID. 
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5.2 Voice group call responsibility 



The MSC responsible for the voice group call is the one nominated within the GCR or the one to which the call is 
routed from the GMSC in the case of a dispatcher originated call. This MSC is termed the group call anchor MSC. 

If the group call area extends beyond one MSC area then any MSCs controlling cells in the area outside of the group 
call anchor MSC are referred to as group call relay MSCs. 

In a RANflex configuration a given location area within the pool area is served (with group call services) by a single 
predefined group call serving MSC which for a specific group call is either anchor or relay MSC. 



Compatibility issues 



VGCS can not be used with standard Phase 1 or Phase 2 mobile stations. A dedicated mobile station with VGCS 
capability is required. 

A mobile station with VGCS capability shall also provide the complete functionality in order to allow the use of 
Phase 2 services. 

Standard Phase 1 and Phase 2 mobile stations in a network shall not be impacted by the presence of VGCS services in 
that network due to VGCS signalling, also if the mobile station is operated with a SIM/USIM of a VGCS service 
subscriber. 



7 Transmission 

7.1 Transmission architecture 

A conference bridge is required to connect the transmission paths of the nominated cells. The bridge is to be located 
within the group call anchor MSC. The group call anchor MSC is responsible for setting up all connections, both to the 
nominated cells (voice group call channels) in the group call anchor MSC (in a RANflex configuration, to those cells of 
the group call area that belong to a location area for which the group call anchor MSC is the group call serving MSC) 
and in any related group call relay MSC, and to the dispatchers. Except when a calling service subscriber, served by a 
relay MSC, is on the initial dedicated link, there shall be one link towards every relay MSC and a distribution function 
in the relay MSCs and from there one link per cell within the group call relay MSC (in a RANflex configuration, per 
cell of the group call area that belongs to a location area for which the group call relay MSC is the group call serving 
MSC) which is involved in the voice group call. While the calling service subscriber is on a dedicated link served by his 
VMSC, there is an additional link from the anchor MSC to the VMSC serving the calling service subscriber and an 
additional link from the VMSC serving the calling service subscriber to the cell serving the calling service subscriber. 
There shall be no secondary bridges in BSCs. 

While a talker served by a relay MSC is on any other dedicated or group channel than the initial dedicated channel , 
the following applies: The distribution function shall be implemented using a secondary conference bridge at the relay 
MSC so that VGCS talker speech sent on the current channel uplink is transmitted to local relay cells as well as being 
transmitted over the link back to the anchor MSC, for distribution to the rest of the network, dispatchers and nominated 
cells at other relay MSCs. 

The conference bridge shall not mute the uplink speech. 

7. 1 a Transmission architecture - A interface circuit sharing 
7. 1 a. 1 Transmission architecture - General 

The MSC and BSC shall negotiate during the setup of a voice group call whether A-interface circuit sharing is 
supported by both entities. When this optional feature is supported by both entities, the same A-interface circuit can be 
shared for all cells belonging to a BSC for a given voice group call. 
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A conference bridge is required to connect the transmission paths of the nominated cells. The bridge is to be located 
within the group call anchor MSC. The group call anchor MSC is responsible for setting up all connections, both to the 
nominated cells (voice group call channels) in the group call anchor MSC and in any related group call relay MSC, and 
to the dispatchers 

The BSC contains a distribution function that distributes speech sent from the MSC to each of the nominated cells. 

7.1a.2 Transmission architecture - Control Plane 

The control plane signalling shall be the same as in sub-clause 7.1. 

7. 1 a.3 Transmission architecture - User Plane 

In the case of an originator that is not on the initial dedicated link, there shall be one link from the anchor MSC towards 
every relay MSC. There will be one link from each of these relay MSCs and the group call anchor MSC to each BSC 
controlled by the respective MSC and involved in the voice group call. Each of these BSCs contains a distribution 
function that distributes speech received from the MSC to each cell involved in the group call. 

When an originator, served by a relay MSC, is on the initial dedicated link, there is an additional link from the anchor 
MSC to the relay MSC serving the originator and an additional link from the relay MSC serving the originator to the 
cell serving the originator. 

When an originator, served by an anchor MSC, is on the initial dedicated link, there shall be one link from the anchor 
MSC towards every relay MSC. There will be one link from each of these MSCs and the group call anchor MSC to 
each BSC controlled by the respective MSC and involved in the voice group call. Each of these BSCs contains a 
distribution function, with one link to each cell and involved in the group call. There is an additional link from the 
anchor MSC to the cell serving the originator. 

While a talker served by an anchor MSC is on any other dedicated or group channel than the initial dedicated channel, 
the following distribution functions shall be implemented: 

- conference bridge at the anchor MSC so that VGCS talker speech sent on the current channel uplink is 
transmitted to local cells as well as being transmitted over the links to the relay MSCs, for distribution to the rest 
of the network, dispatchers and nominated cells at other relay MSCs; 

- distribution point at the BSC so that speech sent from the MSC is distributed to each of the nominated cells. 

While a talker served by a relay MSC is on any other dedicated or group channel than the initial dedicated channel, the 
following distribution functions shall be implemented: 

- secondary conference bridge at the relay MSC so that VGCS talker speech sent on the current channel uplink is 
transmitted to local cells as well as being transmitted over the link back to the anchor MSC, for distribution to 
the rest of the network, dispatchers and nominated cells at other relay MSCs; 

- distribution point at the BSC so that speech sent from the MSC is distributed to each of the nominated cells. 
The conference bridge shall not mute the uplink speech. 

7.1 b Transmission architecture - A interface link sharing 
7. 1 b. 1 Transmission architecture - General 

The MSC and BSC shall negotiate during the setup of a voice group call whether A-interface link sharing is supported 
by both entities. When this optional feature is supported by both entities, the same A-interface link (user and control 
plane) can be shared for all cells belonging to a BSC for a given voice group call. 

A conference bridge is required to connect the transmission paths of the nominated cells. The bridge is to be located 
within the group call anchor MSC. The group call anchor MSC is responsible for setting up a single A-interface link 
(i.e. A-interface circuit and resource controlling SCCP connection) to each BSC containing nominated cells in the group 
call anchor MSC and links to any group call relay MSCs and to the dispatchers. 
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Each BSC is responsible for setting up a speech and signaUing connection (voice group call channel) to each nominated 
cell in the group call area served by this BSC. The BSC contains a distribution function that distributes speech and 
resource control related signalling from the MSC to each of the nominated cells. 

7.1 b. 2 Transmission architecture - Control Plane 

The MSC shall inform the BSC of the cells required to be setup for the group call in the VGCS ASSIGMENT 
REQUEST. This message shall contain the list of group call area cells served by this BSC. If the entire list of cell 
identifiers does not fit into the message or if different methods of radio resource allocation (e.g. "immediate 
allocation"or "delay allowed") are to be used for different cells controlled by the BSC, the MSC shall send one or more 
VGCS AREA CELL INFO messages containing the remaining cell identifiers or the cell identifiers of cells using a 
different method of radio resource allocation. Once a channel could be established to the cell of origin or, if the cell of 
origin is not served by this BSC, to any other cell, the VGCS ASSIGMENT RESULT shall be sent to the MSC and 
timer Tast shall be started. Timer Tast is used to measure the duration between periodic reports from the BSC to the 
MSC of group call area cells for which channels have been assigned or released since the last periodic report. When 
timer Tast expires, if new cells in the group call area have been established or existing ones have been released, pre- 
empted or failed, the MSC shall be informed of the changes. If no changes have taken place nothing shall be sent. Timer 
Tast shall be started again to measure the period of time until the next report. The timer shall be stopped when the call is 
released. 

Once all cells for a given group call area served by a BSC are established this BSC shall immediately send a VGCS 
ASSIGNMENT_STATUS message to the MSC indicating this and restart timer Tast. This information shall be used by 
the MSC to determine the conditions for call set up as described in subclause 11.3.1.1.2. 

The BSS is responsible to establish the channel to the different cells and manage the signalling accordingly (e.g. HO 
decisions, pre-emption, re-establishment of cells, priority uplink decision). The A-interface link (user and control plane) 
between MSC and BSC shall only be released when the call is released. 

When the network supports uplink access option (i) as defined in subclause 7.2 (i.e. indication in uplink busy instructs 
the MS to use the group call channel to send the uplink access message if the talker on the group call channel is not in 
the same cell as the MS) the network shall include talker priority information in all relevant A-interface messages on the 
resource controlling SCCP connection, to distinguish between messages related to the current talker and messages 
related to the subscriber requesting the uplink. 

7.1 b. 3 Transmission architecture - User Plane 

The transmission architecture of the user plane as specified in subclause 7.1a.3 applies. 

7.2 Radio channels 

In each cell of the group call area one voice group call channel may be established consisting of a downlink received by 
all service subscribers' mobile stations and an uplink which shall be used by the talking subscriber's mobile station 
only. 

If the network allocates a dedicated traffic channel for the calling service subscriber, his mobile station shall use the 
dedicated standard uplink/downlink which is connected to the conference bridge up to the instant where the network 
decides that the mobile station shall join the voice group call channel and the dedicated connection is released. 

The network may decide to switch a talking subscriber's mobile station from the voice group call channel to a dedicated 
standard uplink/downlink at any time. The talking subscriber's voice group call channel and the dedicated channel may 
belong to different cells within the group call area, i.e. the network may request the talker to perform a handover. The 
dedicated connection shall then be maintained up to the instance where the network decides that the mobile station shall 
join the voice group call channel again and the dedicated connection is released. 

When the network indicates the uplink as free, the mobile station uses the group call channel uplink to signal an uplink 
request, "emergency mode reset request" or uplink request for sending application- specific data. 

When the network does not indicate the uplink as free, there are two options for the mobile station how to signal an 
uplink request with talker priority higher than "normal subscriber", an "emergency mode reset request" or an uplink 
request for sending application- specific data: 
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i) if the priority uplink access parameter broadcast on the NCH indicates "RACH access" but the latest UPLINK 
BUSY message received in the cell indicates that the group call channel uplink shall be used, the mobile station 
sends an uplink access message on the group call channel uplink; otherwise, the mobile station temporarily 
leaves the group receive mode and sends a channel request message on the RACH. Once a dedicated connection 
has been established by the network, the mobile station sends a layer 3 message PRIORITY UPLINK 
REQUEST or DATA INDICATION 2. The PRIORITY UPLINK REQUEST message contains the MS identity 
(IMSI or TMSI), the group call reference, random reference, the type of request and the token broadcast by the 
BSS, if the ESS broadcasts a token. On receipt of this information, the network shall release the dedicated 
connection, and the mobile station shall return to the group receive mode and continue to listen on the downlink 
of the group call channel for further instructions from the network. 

NOTE 1 : The indication in uplink busy instructs the MS to use the group call channel uplink to send the uplink 
access message if the talker on the group call channel is not in the same cell as the MS. 

If the mobile station releases the uplink on request of the subscriber, it shall use the group call channel uplink for 
signalling subsequent uplink requests, until it performs a cell change or receives either an UPLINK BUSY 
message indicating that RACH shall be used or a VGCS UPLINK GRANT message destined for a different 
mobile station. 

ii) If the priority uplink access parameter broadcast on the NCH indicates "group call channel uplink access" then 
the mobile station always sends an uplink access message on the group call channel uplink. If this option is used, 
the network shall always establish and maintain a dedicated channel for the talking service subscriber. 

NOTE 2: Otherwise, with option (ii) the ESC would not be able to detect the requests of higher privileged talkers in 
the cell where the current talking service subscriber is located. 

Support of both options is mandatory for a mobile station supporting the use of talker priorities or transfer of 
application-specific data and optional for the network. A network supporting the use of talker priorities or transfer of 
time-critical application- specific data shall indicate the default procedure to be used on the NCH (i.e. either "RACH 
access" or "group call channel uplink access"). The indication shall have the same value throughout the network. If the 
"talker channel parameter" is used in a network, then the value of the indication shall be set to "RACH access". 

A listening subscriber's mobile station which responds to a notification because no description of the voice group call 
channel was provided in the notification may be assigned a dedicated standard uplink/downlink up to the instant where 
the radio access network decides that the mobile station shall join the voice group call channel and the dedicated 
connection is released. 

Voice group call channels shall be standard full rate or half rate speech channels, EFR speech channels, full rate AMR 
speech or half rate AMR speech channels. The support of voice group call channels other than full rate speech is a 
network option. A specific voice group call can use either the same speech codec type in all cells of the group call area 
or different speech codec types in different cells of the group call area. Those implementations are optional for the 
network operator. 

When establishing an AMR half rate or AMR full rate speech channel, the BSC shall select a suitable AMR codec 
configuration: 

- for a dedicated channel used by a talking service subscriber, the BSC may select any configuration permitted for 
a point-to-point call; 

- for a voice group call channel the BSC shall select one of the preferred configurations as defined in 3GPP 

TS 28.062 [16], Table 7.11.3.1.3-2. For the downlink the BSC shall disable the rate adaptation mechanism and 
apply a single codec mode until the channel is released. If the talking service subscriber uses the voice group call 
channel uplink and the BSC selected a multi-mode configuration, the BSC shall apply the rate adaptation 
mechanism for the uplink. 

Within a cell the BSC shall select the same codec configuration for all voice group and voice broadcast calls 
using the same AMR codec type, AMR FR or AMR HR, respectively. The selected configuration shall be 
broadcast on the NCH, as long as at least one voice group or voice broadcast call using the respective AMR 
codec type is active. 

When A-interface circuit sharing or A-interface link sharing applies there is one A-interface circuit allocated for the 
group call per BSC. Therefore the same speech codec is applied for all voice group channels in the part of the group call 
area served by one BSC if the TRAU is located between the MSC and the BSC-internal distribution function for speech 
(see subclause T.la.l and T.lb.l). 
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Mobile station using the uplink are in group transmit mode. Signalling for this RR mode is specified in 

3GPP TS 44.018. Mobile stations not using the uplink and not in dedicated mode shall ignore any signalling concerned 

only with uplink usage. 

Full standard duplex channels shall be provided to all dispatchers listed in the GCR. These may be provided either via 
GSM, or via an external network. The links to the dispatchers are connected to the conference bridge. 

If the mobile station of the talking service subscriber joins the voice group call channel, it will transmit on the uplink of 
the voice group call channel. 

7.3 Data confidentiality 

Data confidentiality on the radio can be provided as a network option. 

If data confidentiality is provided, both the uplink and the downlink of the voice group call channel within a cell of the 
group call area shall be ciphered using voice group ciphering keys derived from the same group key, see 3 GPP TS 
43.020 [10]. 

The group key is related to the group ID. For each group ID, there is a number of group keys stored on the USIM which 
are identified by a group key number. The group key number identifying the group key to be used for a particular voice 
group call is provided with the notification to the mobile stations. Mobile stations which have a dedicated connection 
shall be informed of the group key number before they join the voice group call channel. 

USIM based VGCS ciphering uses a concept of short term keys where the short term key is derived by the GCR and the 
USIM from the group key and a RAND (random number) parameter. The actual voice group ciphering key is then 
derived by the BSS and the ME from the short term key, the cell global identifier, and a Cell Global Count parameter. 

To include a subscriber into a voice group the required group data (including the 2 master group keys) shall be stored on 
the USIM, e.g. during the personalisation process or via OTA (over-the-air). To exclude a subscriber from a voice 
group the group data shall be deleted from the USIM. If a USIM is lost or stolen, all USIMs of the remaining members 
of the voice groups that this USIM is a member of need to be changed (e.g. via OTA or manual provisioning). 

Details on data confidentiality for voice group calls are provided in 3GPP TS 42.009 [9]and 3GPP TS 43.020 [10]. 

NOTE 1 : USIM based VGCS ciphering is not compatible with SIM based VGCS ciphering which has not been 

completely specified. The SIM specifications contain no support for the storage of the group keys. A pre- 
Rel-6 VGCS capable mobile station will be able to participate in an un-ciphered group call, if it is part of 
that group. 

If data confidentiality is provided, then for a mobile station in group mode dedicated channel the uplink and the 
downlink of the dedicated channel shall be ciphered using the individual ciphering key of the service subscriber. 

NOTE 2: The individual ciphering key is the key generated during a previous authentication procedure. 

In order to start the ciphering for the calling service subscriber, the MSC serving the mobile station shall initiate a 
cipher mode control procedure during call setup, while the mobile station is in group mode dedicated channel. When 
ciphering was started successfully, the mobile station shall apply the individual ciphering key until it leaves group mode 
dedicated channel or a new cipher mode control procedure is performed successfully. 

In order to start the ciphering on the dedicated channel, if the network decides to move a talking subscriber's mobile 
station from group transmit mode to group mode dedicated channel, the network shall include cipher mode setting 
information in the assignment command or handover command message (see 3GPP TS 43.020 [10], Annex F 3.2). On 
the dedicated channel the mobile station shall apply the individual ciphering key until it leaves group mode dedicated 
channel or a new cipher mode control procedure is performed successfully. 

If data confidentiality is provided, then for a mobile dispatcher the uplink and the downlink of the dedicated channel 
shall be ciphered using the individual ciphering key of the dispatcher. 

If data confidentiality is provided, the priority uplink request procedure can be validated by a handshake between the 
requesting MS and the BSS. A32 bit token is generated randomly and broadcast by the BSS on the ciphered downlink 
of the voice group call channel and stored in the MS. When the MS sends a priority uplink request it includes the token 
as a parameter and the BSS checks this against its stored value. If it matches the request is processed further. If it does 
not match, the request is ignored. A new token is broadcast on the ciphered downlink of the voice group call channel 
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each time a match occurs and each time a periodic UPLINK_BUSY message is sent (i.e. every Tl seconds) (refer to 
Figure 7e in section 11.3.8). 

If data confidentiaHty is provided for point-to-point SMS over the CS domain, the network shall broadcast an SMS data 
confidentiality indication in NOTIFICATION/ NCH messages, NOTIFICATION/ FACCH messages and in the 
Connect message sent to the calling service subscriber of a voice group call. 

If guaranteed privacy is provided for SMS over the CS domain (see 3GPP TS 42.068 [2]), the network shall broadcast 
an SMS guaranteed privacy indication in NOTIFICATION/ NCH messages, NOTIFICATION/ FACCH messages and 
in the Connect message sent to the calling service subscriber of a voice group call. 

NOTE 3: For backward compatibility with legacy networks the coding of these indications in NOTIFICATION 
messages is chosen so that the default settings are SMS data confidentiality = "on" and SMS guaranteed 
privacy = "on". 



8 Information storage 

8.1 Information stored in the GCR 

8.1 .1 Information used for routing of service subscriber originated voice 
group calls 

Without a RANflex configuration, the GCR shall hold for a related MSC area for each group ID and cell from which 
voice group calls can be established by service subscribers the group call reference to be used for a voice group call to 
be established and an indication whether the originating MSC is the group call anchor MSC. 

In a RANflex configuration, the GCR shall hold for a related MSC area (i.e. for those location areas for which the 
related MSC is the group call serving MSC) for each group ID and cell (within those location areas for which the 
related MSC is the group call serving MSC) from which voice group calls can be established by service subscribers the 
group call reference to be used for a voice group call to be established and an indication whether the group call serving 
MSC is the group call anchor MSC. 

Without a RANflex configuration or in a RANflex configuration, if the VMSC is the group call serving MSC: 

If the VMSC is the group call anchor MSC, the GCR shall provide the group call attributes related to that group 
call reference as defined in subclause 8.1.2 to the VMSC and the VMSC shall establish the voice group call. 

If the VMSC is not the anchor MSC, the GCR shall provide the group call reference plus the routing information 
identifying the anchor MSC to the VMSC and the VMSC shall route the voice group call to the anchor MSC. 

In a RANflex configuration, if the VMSC is different from the group call serving MSC: 

If the group call serving MSC is a relay MSC for the group call, the GCR shall provide the group call reference 
plus the routing information identifying the anchor MSC to the group call serving MSC which passes this 
information to the VMSC. 

If the group call serving MSC is the anchor MSC for the group call, the GCR shall provide the group call reference 
to the group call serving MSC which adds the routing information identifying the anchor MSC (i.e. its own MSC 
address) and passes the information to the VMSC. 

Then the VMSC shall route the voice group call to the anchor MSC. 

NOTE: In case the GCR function is distributed over different physical entities, each may hold only the 

information needed to treat requests coming from the MSCs connected to the physical GCR entity. 
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8.1 .2 Group call attributes 



Each MSC involved in a voice group call requests its proper group call attributes from its related GCR. For any group 
call reference the GCR shall provide the corresponding group call attributes to the requesting MSC. These lists shall be 
programmed by the service provider at registration of the network specific service configuration. 

The contents of each list related to requests of the group call anchor MSC is as follows: 

- a list of cells inside the MSC area of the group call anchor MSC (in a RANflex configuration, the cells belonging 
to a location area for which the group call anchor MSC is the group call serving MSC) into which the call is to 
be sent (part of the group call area), see subclause 8.1.2.1; 

- a list of group call relay MSCs into which the call is to be sent; 

- information on the cipher algorithm and the group key to be used for this voice group call; 

- information on the codecs allowed for this voice group call. As an operator option, the EFR codec, standard half 
rate codec, AMR half rate codec, and AMR full rate codec can be supported; 

NOTE: A pre-Rel-7 VGCS capable mobile station will not be able to participate in a group call using the EFR 
codec, AMR half rate codec or AMR full rate codec, if the mobile station is part of that group 

- a list of identities of dispatchers to which a dedicated link is to be established, see subclause 8.1.2.2; 

- a list of identities of dispatchers which are allowed to initiate the voice group call, see subclause 8.1.2.2; 

- a list of identities of dispatchers which are allowed to terminate the voice group call, see subclause 8.1.2.2; 

- the length of time over which no activity is detected before the voice group call is automatically terminated, see 
subclause 8.1.2.3; 

- the default priority level related to the voice group call if eMLPP applies, see subclause 8.1.2.4; 

- a status flag indicating if a voice group call with the related group call reference is on-going, see 
subclause 11.3.1.1.1; 

- a talker channel parameter indicating if the network shall always establish and maintain a dedicated channel for 
the talking service subscriber; 

- an indication whether the uplink reply procedure is applicable for this voice group call. 
The contents of each list related to requests of a group call relay MSC is as follows: 

- a list of cells inside the MSC area of the requesting MSC (in a RANflex configuration, cells belonging to a 
location area for which the requesting MSC is the group call serving MSC) into which the call is to be sent (part 
of the group call area), see subclause 8.1.2.1; 

- identity of the group call anchor MSC; 

- a status flag indicating if a voice group call with the related group call reference is on-going, see 
subclause 11.3.1.1.1. 

8.1.2.1 Group call area 

The group call area is defined as a list of cells inside the network. The cells shall be defined by their cell identification 
consisting of the Location Area Code and the Cell Identity as defined in 3GPP TS 24.008 and are therefore uniquely 
identified in the network. 

In the case the group call area extends over several MSCs, only the cells belonging to the requesting MSC (in a 
RANflex configuration, cells belonging to location areas for which the requesting MSC is the group call serving MSC) 
are included in the group call attributes. 
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8.1 .2.2 Dispatcher identities 

Dispatcher identities shall be ISDN numbers or MSISDN numbers with the structure according to 

ITU-T Recommendation E.164. They shall correspond both to the number to be used to establish a call toward the 

dispatcher and the number provided as calling line identification when the call is originated by a dispatcher. 

The list of dispatcher identities is used by the anchor MSC to establish dedicated communication paths to each 
dispatcher and connect them to the conference bridge of the call. 

The list of dispatcher identities which are allowed to initiate voice group calls is used by the anchor MSC for 
verification for a voice group call establishment by a dispatcher. 

The list of dispatcher identities which are allowed to terminate voice group calls is used by the anchor MSC for 
verification for a voice group call release by a dispatcher. 

8.1.2.3 No activity time 

A timer in the anchor MSC used to release the voice group call because of "no activity" can be set to a fixed value or 
can be set to a value defined for each voice group call. 

A group call is defined to be in the state of "no activity" in the anchor MSC, if the following conditions are all fullfilled: 

- the uplink is free; 

- no dispatcher is connected; 

- no short message is waiting in the anchor MSC to be sent to the voice group call; and 

- no application- specific data are waiting in the anchor MSC to be relayed. 

The anchor MSC shall check for the state of "no activity" if any of the following events occur: 

- an uplink release is indicated to the anchor MSC; 

- a dispatcher leaves the ongoing group call; 

- the anchor MSC has completed the distribution of a short message to the voice group call; or 

- the anchor MSC has completed the relay of application-specific data. 

The anchor MSC has to start the "no activity" timer, when the conditions for "no activity" are all fulfilled. 
The timer shall be stopped and reset each time any of the following events occurs: 

- an uplink request is indicated to the anchor MSC; 

- a dispatcher joins the ongoing group call; 

- a short message to the voice group call is received by the anchor MSC; or 

- application-specific data are received by the anchor MSC. 

When a variable timer is provided, there shall be sufficient timers such that one can be associated with each on-going 
group call. The corresponding time shall be stored in the GCR. 

The length of the timer is not specified in the GSM technical specifications. 

8.1.2.4 Priorities 

If the eMLPP supplementary service is applied to a voice group call, the priority level shall be stored in the GCR. For 
further details see 3GPP TS 23.067. 
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8.1.3 Transient GCR Data 

The relay MSC, and in a RANflex configuration the group call serving MSC of the initiating service subscriber's 
current LAC, if this MSC is different from the VMSC, interrogate the GCR twice when setting up the voice group call: 
The first GCR interrogation is triggered in the relay MSC by the service subscriber or in a RANflex configuration in the 
group call serving MSC by the MAP service SEND_GROUP_CALL_INFO received from the VMSC. The second 
GCR interrogation is triggered in the relay MSC by the MAP service Prepare Group Call or in a RANflex 
configuration, if the anchor MSC is the group call serving MSC, by receiving the lAM from the VMSC. 

At the first GCR interrogation the GCR shall store transient data in the GCR which are retrieved with the second GCR 
interrogation. These data are: 

- the initiating service subscriber's IMSI; 

- the initiating service subscriber's talker priority; 

- the initiating service subscriber's additional information; and 

- the originating cell id. 

8.2 Information managed per subscriber 

8.2.1 Stored! n the HLR 

The following additional information shall be stored in the HLR: 

- the subscription option for voice group calls which can be made in the HPLMN only or also in case of roaming; 

- a list of all the group IDs a service subscriber is entitled to use. 

- optionally, for each group ID a list of the talker priorities the service subscriber is allowed to use. The permission 
to use talker priority "normal subscriber" is implied by the subscription for the group ID and does not need to be 
stored explicitly; 

Editor's note : Whether the HLR additionally stores for each group ID if the subscriber is allowed to transmit 
application-specific data is ffs. 

- optionally, an information element containing operator specific additional information about the subscriber. 
The group IDs are defined in subclause 9.L 

A service subscriber shall not be provided with more than 50 group IDs. 

8.2.2 Stored in the VLR 

The list of all the group IDs and related subscription data a service subscriber is entitled to use shall be brought forward 
to a VLR at the same time as other subscriber information is copied, and VLR entries shall be modified when 
corresponding HLR records are changed. 

8.2.3 Stored in the SIIVI 

The information detailed in subclause 8.2.1, except for the operator specific additional information about the subscriber, 
also needs to be stored on the SIM. The service subscriber shall be able to deactivate or reactivate a group ID by MMI 
interaction so that the mobile station ignores notification messages to this group ID, when the group ID is deactivated. 

8.2.3a Stored in the USIIVI 

The information detailed in subclause 8.2.1, except for the operator specific additional information about the subscriber, 
also needs to be stored on the USIM. The service subscriber shall be able to deactivate or reactivate a group ID by MMI 
interaction so that the mobile station ignores notification messages to this group ID, when the group ID is deactivated. 
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For each group ID where data confidentiality may be appHed, the USIM needs to store the cipher algorithm to be used 
and the possible group keys. 

For each group ID the USIM needs to store indications whether the service subscriber is allowed to transmit 
application-specific data. 

8.3 Information used for routing of dispatciier originated voice 
group calls 

Routing of dispatcher originated calls shall be performed on the MSISDN number received at a GMSC in the 
Initial_ Address_Mes sage . 

- Because the group call reference is included in the called MSISDN number as defined in subclause 9. 2d the 
routing information can be derived by the routing function of the GMSC. The GMSC afterwards directly routes 
the call request to the group call anchor MSC without requesting an HLR. 



9 Identities 

9.1 Elementary identities for group calls 

a) Group ID 

The group ID is a sequence of decimal digits with a maximum length depending on the composition of the group call 
reference defined under c). The length of Group ID shall be in a range of 1 to 8 digits. 

The mobile station derives the group ID from the group call reference by identifying the longest group ID amongst 
those stored in the SIM/USIM and matching the least significant digits of the group call reference. If no group ID is 
stored in the SIM that matches the least significant digits of the group call reference, the mobile station is not able to 
derive the group ID from the group call reference. 

NOTE 1 : The network should use Group IDs matching an initial part of other group IDs with greatest care, if at all. 

EXAMPLE: A mobile station storing the group IDs 678, 2 678 and 42 678 (and only those) in the SIM will 
derive group ID 2 678 from group call reference 13 452 678. 

For definition of Group ID on the radio interface, A interface and Abis interface, see 3GPP TS 44.068 [11]. 

For definition of Group ID coding on MAP protocol interfaces, see 3GPP TS 29.002 [13]. 

b) Group call area ID 

The group call area ID is a sequence of decimal digits uniquely assigned to a group call area in one network and with a 
maximum length depending on the composition of the group call reference defined under c). 

c) Group call reference 

Each voice group call in one network is uniquely identified by its Group call reference. The group call reference is a 
concatenated sequence of the group ID (as the least significant part) and the group call area ID (as the most significant 
part). The group call reference shall have a maximum length of 8 decimal digits. The composition of the group call area 
ID and the group ID can be specific for each network operator. 



Group call area ID Group ID 



The group call reference is equal to the group ID when the group ID has a length of 8 decimal digits. 

For definition of Group Call Reference (with leading zeros inserted as necessary) on the radio interface, A interface and 
Abis interface, see 3GPP TS 24.008 [7], 3GPP TS 44.018[5] and 3GPP TS 44.068 [11]. 
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For definition of Group Call Reference coding (also known as ASCI Call Reference, Voice Group Call Reference or 
Voice Broadcast Call Reference) on MAP protocol interfaces, see 3GPP TS 29.002 [13]. 

9.2 Use of identities in the network 

For each voice group call the identifications as defined in the following shall be used within the network for the related 
purpose mentioned. 

For voice group call services which are to operate in more than one PLMN, group identities have to be co-ordinated 
between the network operators involved. 

a) Identities used for GCR requests for service subscriber originated voice group calls 

For a service subscriber originated call, the identity of the call used by the MSC in which the call is originated to 
interrogate the GCR shall consist of the originating serving cell identity as defined in 3GPP TS 48.008 and the group ID 
as defined in subclause 9.1. In a RANflex configuration the same identity is used by the group call serving MSC to 
interrogate the GCR when it receives the MAP Send Group Call Info service. 



Originating cell ID 


Group ID 



A service subscriber initiating a voice group call has to call the wanted group ID. The MSC in which the call is 
originated shall accumulate from the BSS the called group ID and the originating cell ID. 

If the group call area exceeds one MSC area, the identity used to interrogate the GCR by an MSC in which the call was 
not originated shall consist of the group call reference as defined in subclause 9.1, except for the case in a RANflex 
configuration where the GCR interrogation in the group call serving MSC is triggered by receipt of the MAP Send 
Group Call Info service. 

If the group call area exceeds one MSC area and the call was originated 

- in a relay MSC; or 

- in a RANflex configuration in a location area for which a relay MSC is the group call serving MSC, 

this relay MSC will perform a second GCR interrogation when the anchor MSC sets up the link to the relay MSC (see 
subclause 1 1.5). The relay MSC shall use the group call reference as defined in subclause 9.1 as the identity for the 
second GCR interrogation. 

b) Identities used for GCR requests for dispatcher originated voice group calls 

In case of dispatcher originated call the identity used by the MSC to interrogate the GCR shall consist of the group call 
reference as defined in subclause 9.1. 

c) Identities used for notifications to service subscribers 

Identities used for notification messages shall consist of the group call reference as defined in subclause 9.1. 

d) Identities used by dispatchers for voice group call establishment 

For dispatcher originated calls an MSISDN is dialled. The Country Code (CC) and National Destination Code (NDC) 
are used as normal for routing purposes. The CC and NDC may be omitted for internal calls. The numbering scheme is 
based on ITU-T Recommendation E.164. The Subscriber Number (SN) is used to indicate: 

- the request of a group call by use of a prefix. The length of the prefix shall be 1 to 2 digits; 

- the wanted group call reference as defined in subclause 9.1. 
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cc 


NDC 


Prefix 


Group call reference 



e) Identities used for VLR requests for service subscriber originated group calls 

The group ID shall be used on the B -Interface for VLR requests. 

f) Anchor MSC address for routing of service subscriber originated calls from originating MSC to anchor MSC 

For service subscriber originated calls an anchor MSC address is used as called party address to route the call from the 
originating MSC to the anchor MSC. The anchor MSC address structure is the same as for dispatcher originated calls 
(see subclause d)) The Country Code (CC) and National Destination Code (NDC) are used as normal for routing 
purposes. The numbering scheme is based on ITU-T Recommendation E.164. The Subscriber Number (SN) is used to 
indicate: 

- the request of a group call by use of a prefix. The length of the prefix shall be 1 to 2 digits; the actual value of the 
prefix may be different than the one dialled by dispatchers. 

- the wanted group call reference as defined in subclause 9.1. 



cc 


NDC 


Prefix 


Group call reference 



g) Identities used for notifications to dispatchers 

Identities used for notification messages to dispatchers shall be identical to those used by dispatchers to initiate calls as 
described in subclause d). 

A notification identity is presented to a dispatcher terminal by making use of CLIP. Between the anchor MSC and MSC 
to which the dispatcher is attached, the information may be carried using the Calling Party Number parameter or 
Generic Number Parameter as agreed between the network operators. The Country Code (CC) and National Destination 
Code (NDC) are used as normal for routing purposes. The numbering scheme is based on 
ITU-T Recommendation E.164. The Subscriber Number (SN) is used to indicate: 

- the indication of a group call by use of a prefix. The length of the prefix shall be 1 to 2 digits; the actual value of 
the prefix shall be the same as the one dialled by dispatchers 

- the group call reference as defined in subclause 9.1. 



cc 


NDC 


Prefix 


Group call reference 



The Screening Indicator shall be set to "Network Provided" 
The Type of Number shall be set to "International" 



1 Operation and maintenance aspects 

NOTE: A list and short description of the operation and maintenance aspects will be given. This includes the 
options and parameters which can be set by the operator: 

handling of timers; 

- registration aspects; etc. 
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1 1 Function and information flows 

11.1 Group management 

The group call attributes, as given in subclause 8.1 shall be entered and modified by the service provider. A list 
providing information on necessary Operation and Maintenance actions is given in clause 10. 

1 1 .2 Group membership management 

Once the membership is established, the individual membership of the group can be placed in an active or deactive state 
on the SIM/USIM by the user. If a subscriber has a group ID in an active state, the subscriber is able to establish voice 
group calls corresponding to that group ID. 

In a deactive state the mobile station prevents the service subscriber from establishing calls using the group ID and the 
corresponding notifications need to be "ignored" by the mobile station. 

The active state and deactive state entries may be password protected as an implementation option. 

Group IDs are listed in the subscription data within the network and on the SIM/USIM. The SIM/USIM must be 
returned to the network operator or service provider for updating if the subscription is to be changed. 

NOTE: Updating of subscription data over the radio interface is not considered. However, this shall not preclude 
future applications if corresponding mechanisms may be implemented. 

Users can interrogate their mobile stations to determine to which groups they are members and which subscriptions are 
currently in an active state. 

11.3 Call management 
11.3.1 Call establishment 

A voice group call can be established by either a service subscriber or by a dispatcher. 

1 1 .3.1 .1 Service subscriber call establishment 
11.3.1.1.1 Initial stage 

The initial signalling from the calling service subscriber informs the network that a voice group call is required and 
details the group ID; it may specify originator-to-dispatcher information. No information relative to the group call area 
is given by the calling service subscriber. 

The network shall perform a number of checks in order to determine how to handle the call: 

- check of the ability of the subscriber to establish the call; 

- check whether the call can be initiated from the cell; 

- check of the existence of an on-going call of the same group call reference. 

The originating MSC shall check the VLR records for the ability of the subscriber to start the call. If the service 
subscriber has no subscription for the voice group call service with the indicated group ID, the call shall be released. In 
addition, the VLR shall return barring and identity presentation restriction checks to the MSC. 

In a RANflex configuration the originating MSC shall then derive the group call serving MSC address from the 
originating location area. If the group call serving MSC is different from the originating MSC then the group call 
serving MSC's GCR is interrogated by means of the MAP service SEND_GROUP_CALL_INFO. The interrogation 
request contains the originating Cell Id and the Group Id. It also contains the initiating service subscriber's IMSI, the 
actual talker priority, and subscribed additional information. If the group call serving MSC is a relay MSC for the group 
call, then its GCR shall derive the anchor MSC address and the group call reference from the originating Cell Id and 
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Group Id, and return it to the VMSC. If the group call serving MSC is the anchor MSC for the group call, then its GCR 
shall derive the group call reference from the originating Cell Id and Group Id, and return it to the VMSC. 

Without RANflex configuration or if in a RANflex configuration the originating MSC is the group call serving MSC 
(derived from the originating location area) it shall then request information from the GCR by giving the group ID and 
the originating cell ID as defined in subclause 9.2. 

If the length of the group ID is less than 8 decimal digits, the GCR first derives the group call area ID from the group ID 
and the originating cell ID. If no group call area ID is related to the group ID and originating cell ID, the call shall be 
released. If a group call area ID is related to the group ID and originating cell ID, the GCR shall transfer the 
corresponding group call attributes to the MSC. From that moment until the MSC indicates the contrary, the call shall 
be considered as on-going by the GCR. 

If the group ID has a length of 8 decimal digits, the group call reference is equal to the group ID. The GCR shall check 
whether the call was initiated within the group call area stored in the GCR. If not, the call shall be released; otherwise, 
the GCR shall transfer the corresponding group call attributes to the MSC. From that moment until the MSC indicates 
the contrary, the call shall be considered as on-going by the GCR. 

The GCR of the relay MSC and in a RANflex configuration, if the group call serving MSC of the initiating service 
subscriber's current LAC is different from the VMSC, the GCR of this group call serving MSC shall store the initiating 
service subscriber's IMSI, talker priority, additional information and originating cell id for later processing. 

If the originating MSC is not the group call anchor MSC for the voice group call as indicated in the GCR, then the voice 
group call request shall be passed to the group call anchor MSC; in that case, if the initiation of the voice group call had 
specified originator-to-dispatcher information and processing of originator-to-dispatcher information is supported by the 
MSC, the originator-to-dispatcher information is transformed by the originating MSC into UUSl and sent to the anchor 
MSC. 

Without RANflex configuration or if in a RANflex configuration the originating MSC is the group call serving MSC, it 
shall additionally include the address of the originating relay MSC in the calling party number of the lAM when passing 
the call request to the anchor MSC. In a RANflex configuration, if the originating MSC is different from the group call 
serving MSC, the VMSC shall include the address of the group call serving MSC in the calling party number of the 
lAM. 

If the group call reference is composed of Group ID and group call area ID, it is possible that two service subscribers or 
a service subscriber and a dispatcher or two dispatchers may attempt to establish a call using the same group ID and 
corresponding to the same group call area ID. If the two voice group calls are established with the same group ID but 
for different group call areas then separate voice group calls shall be established. If the group call areas overlap, it is up 
to receiving mobile station to determine which call to participate in. If more than one call is made to identical group ID 
and group call area, the network shall reject all but one of the call attempts. 

If the group ID has a length of 8 decimal digits, if more than one call attempt is made to the same group ID, the network 
shall reject all but one of the call attempts. 

A service subscriber which is entitled by his subscription to establish voice group calls while roaming shall only be able 
to use supra-PLMN group IDs as defined in subclause 9.1 in case of roaming. In case of roaming, the mobile station 
shall only react on notifications for supra-PLMN group IDs. 

If the GCR receives a new interrogation related to a group call reference where the call is indicated as on-going in the 
GCR, the GCR shall provide the on-going status together with the group call reference back to the MSC. The MSC 
shall then release the call with a cause user busy in case of a service subscriber originated call request. The mobile 
station of the service subscriber shall then look for notifications of the respective group ID on the NCH and join the 
voice group call. In case of a dispatcher originated voice group call request, the MSC shall join the dispatcher to the 
conference bridge of the voice group call. 

If the group ID has a length of 8 decimal digits, the operator can define for this group ID only one group call and one 
group call area within his network. If the length of the group ID is less than 8 decimal digits, the operator can define 
more than one group call using the same group ID, but different group call areas. Because of the possibility of 
overlapping group call areas, each call requires a unique reference, assigned by the GCR related to the originating MSC 
or the group call serving MSC (in a RANflex configuration). The group call reference shall be composed of the group 
ID and a group call area ID (see clause 9). 

Authentication of the calling service subscriber can be performed by the network as for normal calls. 
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1 1 .3.1 .1 .2 Establishment of the transmission means 

A voice group call channel shall be established in all the cells throughout the identified group call area using physical 
channels selected by the BSCs as appropriate. The downlink channels shall be established without any return signalling 
from mobile stations. Whilst the downlink channel is being established, the MSC shall form a conference bridge 
containing the appropriate channels to all BTSs in the group call area or in case of A-interface link sharing to all BSCs 
in the group call area. The MSC is responsible for adding dispatchers to the conference bridge. 

Alternatively, the network may establish voice group call channels in a cell on demand, i.e. if mobile stations respond to 
the notifications as defined in subclause 4.2.2.1 (see "uplink reply procedure"). As a network option the applicability of 
the uplink reply procedure for a voice group call can be controlled by the GCR of the anchor MSC. If the anchor MSC 
supports this feature, it shall allow all affected BSCs to establish voice group call channels on demand only if the GCR 
indicates that the uplink reply procedure is applicable. If the relay MSC supports this feature, it shall allow all affected 
BSCs to establish voice group call channels on demand only if the anchor MSC indicates during the establishment of 
the voice group call that the uplink reply procedure is applicable. 

In parallel, a dedicated suitable traffic channel may be allocated to the calling service subscriber if not already the case. 

If the "talker channel parameter" is used and indicates that the network shall always establish and maintain a dedicated 
channel for the talking service subscriber, a dedicated suitable traffic channel shall be allocated to the calling service 
subscriber. If there are not sufficient radio resources in the originating cell to allocate a dedicated channel and a group 
call channel, the group call establishment fails and the voice group shall be released. 

The call will be considered established provided that at least the downlink channel in the originating cell, in the case of 
a service subscriber originated voice group call, or the downlink channel in any one cell within the group call area, in 
the case of a dispatcher originated voice group call, is established. The MSC shall signal to the calling service 
subscriber that this has occurred so that he knows when to start speaking. If a voice group call does not meet the above 
conditions in a pre-set time (Txx) then the call shall be released. 

The mobile station shall indicate connection to the subscriber. If channels could not be established in particular cells 
because of congestion, channels are allocated to these cells as soon as possible. 

The MSC may retry the VGCS Assignment procedure to establish channels in cells where they are missing. If 
supported, the procedure may be initiated when: 

i) congestion (i.e. a lack of A-interface circuits) prevented the VGCS ASSIGNMENT REQUEST message from 
being sent to the BSS; 

ii) a VGCS ASSIGNMENT FAILURE message is received and the cause value indicates an acceptable reason for 
retry (e.g. no radio resource available); 

iii) the radio and terrestrial resources for the group call channel are cleared (group call on-going) and the cause value 
indicates an acceptable reason for retry (e.g. pre-emption); 

iv) no response to the VGCS ASSIGNMENT REQUEST message is received (this is determined by the MSC in an 
implementation-dependent manner such as expiry of a timer); or 

v) no response is received following receipt of a VGCS QUEUING INDICATION (this is determined by the MSC 
in an implementation-dependent manner such as expiry of a timer). 

NOTE: If A-interface link sharing or group call re-establishment by the BSS apply, the BSC is responsible for 
establishing/re-establishing channels in cells and scenario (ii) and (iii) do not apply, unless A-interface 
resources also need to be re-established (e.g. when the PCM system serving the A-interface circuit fails 
(equipment failure)). Scenario (v) does not apply to A-interface link sharing and group call re- 
establishment by the BSS. 

The MSC may repeat the VGCS assignment procedure until a VGCS ASSIGNMENT RESULT message is received, 
the call is released or an unacceptable reason for retry (e.g. protocol error between BSS and MSC) is received by the 
MSC. The time between subsequent retries is implementation-dependent. The MSC shall send each retry of the VGCS 
ASSIGNMENT REQUEST over a new resource-controlHng SCCP connection. 

If a message is received with an unacceptable reason for retry then existing procedures apply. I.e. the MSC shall initiate 
the clearing of the radio and terrestrial resources, if necessary, and no further attempts to establish a group call channel 
in the cell are made. 
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While using the retry procedure the MSC shall maintain the call controlling SCCP connection to a BSS until the call is 
released or until the MSC decides to stop any further attempts to establish group call channels for the call on a BSS 
where no cells are established. 

1 1 .3.1 .1 .3 Release of the dedicated transmission means of the calling service subscriber 

The calling service subscriber shall be given a dedicated connection up to the time where the network requests him to 
join the voice group call channel. If the calling service subscriber is not talking, the network requests him to join the 
voice group call channel as a listener by use of a channel release procedure. Otherwise, the network shall request him to 
join the voice group call channel as a talker by either a channel assignment procedure or a handover procedure or a 
channel mode modify procedure. 

If the "talker channel parameter" is used and indicates that the network shall always establish and maintain a dedicated 
channel for the talking service subscriber, then the network shall not request the calling service subscriber to join the 
group call channel as long as he is talking. 

For the time when the voice group call is established until the calling service subscriber becomes a listening service 
subscriber for the first time, the "uplink busy" flag is set (see subclause 11.3.8). Mobile stations shall be programmed 
such that if they originate the call, they indicate to the user that it is required that an indication of the desire to speak 
should be made if he wants to speak. If this is not done within a certain time, the mobile station sends an UPLINK_REL 
message to the network and the uplink shall become free. 

1 1 .3.1 .1 .4 Release of the dedicated transmission means of mobile stations responding to a 
notification 

Mobile stations which respond to a notification for which no description of the voice group call channel was given in 
the notification message may be given a dedicated connection up to the time where the network requests the mobile 
station to join the voice group call channel. If the service subscriber is not talking, the network requests him to join the 
voice group call channel as a listener by use of a channel release procedure. Otherwise, the network shall request him to 
join the voice group call channel as a talker by either a channel assignment procedure or a handover procedure or a 
channel mode modify procedure. 

11.3.1.1.5 void 

11.3.1.1.6 void 

1 1 .3.1 .2 Dispatcher call establishnnent 

In the case of dispatchers originated calls the call request, in the form of an MSISDN number, shall be received at a 
GMSC. Such a call can be treated by the GMSC as a normal mobile terminated call. In this case, the GMSC shall 
interrogate an HLR, determined on the basis of the MSISDN number. The HLR in turn may either interrogate the 
appropriate MSCA^LR to obtain an MSRN, or may supply an MSRN predefined in the HLR and related to the 
respective group call reference in the MSC/VLR. If the HLR interrogates the MSC/VLR for the MSRN, the HLR shall 
provide this MSCA^LR with the related IMSI including the group call reference as defined in clause 9. 

Alternatively, the call request can be forwarded directly to the related group call anchor MSC on basis of the GMSC's 
internal routing table. In this case, the group call reference shall already be included in the requested MSISDN number 
as defined in clause 9. 

When interrogated by the group call anchor MSC, the GCR shall check if the calling line identity is within the list of 
dispatcher identities allowed to establish the voice group call. If not the case, the call shall be rejected. 

After reception of the call request, the group call anchor MSC checks whether an on-going call of the same group call 
reference exists, in which case the group call anchor MSC shall add the dispatcher to the call. 

At the point at which notification messages are sent to mobile stations, a tone is relayed to the calling dispatcher to 
inform the dispatcher that the message can commence. 
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1 1 .3.1 .3 Notification procedures 

Different notification procedures shall be applied in relation to the mode of the mobile station as presented in Table 1 
and Table 2 and defined in the following sections. 

Table 1 : Overview on different information messages for new or on-going calls 



Incoming call type: 
MS states: 


VBS or VGCS call 


point-to-point call 


Idle mode 


(section a) 


(standard paging) 


Group mode, dedicated 
channel 


(section b) 


(section c) 


group receive mode and 
group transmit mode 


(section b) 


(section c) 


dedicated mode 


(section b) 


(standard Call Waiting) 
(note) 


NOTE: only for point to point calls with certain restrictions as defined in 
3GPP TS 22.083. 



Table 2: Overview on different information messages for incoming point-to-point short messages 



MS states: 


Incoming point-to-point short messages 


Idle mode 


(standard paging) 


group mode, dedicated 
channel 


(standard SMS delivery) (note) 


group receive mode 


(section c) 


group transmit mode 


(standard SMS delivery or section c) (note) 


dedicated mode 


(standard SMS delivery) (note) 


NOTE: see subclause 1 1 .3.9.2. 



a) Notification for mobile stations in idle mode 

Once the voice group call channel has been established in a cell or the network is waiting to receive notification 
responses to establish a voice group call channel, notifications shall be broadcast on the NCH in that cell. 

The position of the NCH is derived from the system information of the BCCH. 

The notification messages shall include the group call reference and possibly the description of the voice group call 
channel, the call priority if eMLPP is applied, the group cipher key number, and the emergency mode indication, if 
applicable. 

A notification message can contain no, one or more notifications. 

The notification process needs to continue throughout the duration of the group call, in order to permit the "late entry" 
of other mobile stations. Mobile stations moving into the group call area which are in idle mode shall be directed to the 
voice group call channel by the notification messages, possibly by means of the notification response procedure. 

The scheduling of the notification messages in a cell shall be managed by the BSS. Information can be added in the 
messages to limit the required reception of NCH messages. The following constraints shall be met: 

- the three first initial notifications (i.e. the first for a given group call) shall have priority over subsequent 
notifications (i.e. the messages for an on-going group call) and must be sent as soon as possible; 

NOTE 1 : In addition initial notification messages for calls with or above an operator defined priority level can be 
sent on all possible paging or access grant channels to reduce the delay for those mobile stations which 
are not using Discontinuous reception (DRX). 

- afterwards, an on-going group call in the cell shall be periodically notified on the NCH. 

Since the information for the establishment of a voice group call is sent onto the NCH rather than on the PCH as for 
normal point-to-point calls, the mobile station must listen to the PCH as well as to the NCH. A "reduced NCH 
monitoring" mechanism can be used to save power in the mobile station when listening to the NCH. 

A mobile station able to receive voice group calls either, depending on the implementation: 
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- can use the "reduced NCH monitoring" mechanism. When entering a cell, the mobile station shall listen to the 
NCH to get the notifications of the voice group calls on-going in the cell. Afterwards, the mobile station needs to 
listen to the NCH only if it is informed on the availability of a notification for a new voice group call. This shall 
be based on the NCH status information provided, as indicated in 3GPP TS 44.018; 

- do not apply the "reduced NCH monitoring" mechanism and read all possible paging or access grant channels. 

b) Notifications for mobile stations in group mode dedicated channel, group receive, group transmit or 
dedicated mode 

In addition to sending initial notification messages on the NCH for the voice group call, the BSS can provide initial 
notification into on-going voice broadcast, group calls and point to point calls informing mobile stations partaking in 
these calls of new voice group calls that are being set-up in the cell. 

NOTE 2: The additional notification into on-going voice broadcast and group calls and point to point calls should 
be provided by the BSS if the priority level of the new call is equal or higher than the O&M defined 
priority level. 

In order to do this the BSS sends initial notification messages on FACCH to all other ongoing voice broadcast, group 
calls, and point to point calls in the cell. The initial notification message on FACCH shall contain the group call 
reference, the priority level if eMLPP applies, possibly the TCH description which allows the mobile station to connect 
directly to the new call without reading the NCH, and the emergency mode indication, if applicable. 

An indication of change of notifications in the current cell may be provided on SACCH by the BSS. 

When the emergency mode is set or reset for a voice group call ongoing in a cell, the BSS shall send additional 
notifications on FACCH to all on-going voice broadcast, group calls, and point-to-point calls in the respective cell. 

As a mobile station option, the mobile station may read the NCH of the current cell while in group mode dedicated 
channel, group receive, group transmit or dedicated mode in order to be notified on other voice group calls. 

NOTE 3: Mobile stations may require an additional receiver to read the NCH in order to ensure a higher probability 
of receiving notifications for all present voice group calls without degradation of the received speech 
quality. 

Late entry of mobile stations into ongoing high priority group calls and voice group calls in emergency mode is covered 
by the following mechanisms: 

- Late entrance in dedicated mode 

If a mobile station in dedicated mode is moving into an area where a group call (VGCS or VBS) with priority 
level equal or higher to an operator specific setting or a voice group call in emergency mode is ongoing, the 
BSS shall resend the notification message to the mobile station on FACCH, if the mobile station has ASCI 
capabilities. This notification shall be triggered by completion of the dedicated channel assignment. 

Sending periodical notification on FACCH to the mobile station in dedicated mode is optional, and is done as 
long as the group call (VGCS or VBS) with priority level equal or higher to an operator specific setting, is 
ongoing or as long as the emergency mode is set for the voice group call, with a repetition period given by an 
operator specific setting. 

- Late entrance in group receive or group transmit mode 

When a group call (VGCS or VBS) with priority level equal or higher to an operator specific setting, is 
established, or when the emergency mode is set for a voice group call, the BSS shall send periodical 
notification on FACCH to all ongoing voice broadcast and group calls in the cell, except on the FACCH of 
the group call (VGCS or VBS) which has initiated this periodical notification. By this method the mobile 
station in group receive or group transmit mode moving into this cell is notified. Periodical notification on 
FACCH is done as long as the group call (VGCS or VBS) with priority level equal or higher to an operator 
specific setting, is ongoing, or as long as the emergency mode is set for the voice group call, with a repetition 
period given by an operator specific setting. 

NOTE 3a: The operator determined Periodical FACCH notification period shall be a BSS specific operator setting 
and be a minimum of Is and maximum of 5s. 
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c) Paging into on-going voice group calls 

Paging into on-going voice group calls shall be provided as an implementation option. 

In addition to establishing the links for the voice group call, the network can provide paging information into on-going 
voice group calls informing mobile stations partaking in a voice group call of new incoming point-to-point calls. The 
network can also provide paging information into ongoing voice group calls informing mobile stations in group receive 
mode or group transmit mode of incoming point-to-point short messages. 

The mobile station shall be ready to receive a paging message on the FACCH containing the mobile subscriber identity 
and the priority level if eMLPP applies. 

In the event of a reorganisation of the PCH the BSS shall inform the mobile stations via the SACCH that paging 
reorganisation has occurred. A mobile station receiving this indication shall decode the BCCH in order to obtain the 
new paging configuration. 

As a mobile station option, the mobile station may read its paging subchannel in the current cell in group receive mode 
or group transmit mode in order to receive paging messages. 

NOTE 4: Mobile stations may require an additional receiver to read its PCH subchannel in order to ensure a higher 
probability of receiving all relevant paging messages without degradation of the received speech quality. 
The additional receiver may be the same as used for reception of the NCH described under b) above. 

1 1 .3.1 .4 Destination service subscribers 

Mobile stations of destination service subscribers which are in idle mode shall listen to notification messages on the 
NCH and move to the voice group call channel or respond to the notification. 

Mobile stations which are busy shall either pre-empt the current call (if eMLPP is applied and the new call is of a 
sufficient priority), or shall provide the service subscriber with an indication similar to call waiting, when applicable. 

1 1 .3.1 .5 Destination dispatchers 

Destination dispatchers are connected into the voice group call as a standard point-to-point call. The notification of the 
identity of the received group call shall be supplied in the Calling Line Identity, formatted according to sub-clause 9.2. 

1 1 .3.2 Call release 

The voice group call can be terminated by the calling service subscriber or the calling dispatcher clearing it down, or by 
any dispatcher nominated in the GCR allowed to terminate the call. 

1 1 .3.2.1 Call termination by the calling subscriber 

The calling service subscriber will need to gain the uplink before he can issue a termination request. 

If the mobile station uses the uplink with a talker priority different from "normal subscriber" it shall include this talker 
priority in the termination request message. If the network supports uplink access option (i) as defined in subclause 7.2 
and A-interface link sharing applies, the MSC shall compare the talker priority included in the termination request 
message with the talker priority stored for the current talker. If they are equal, the termination request is processed 
further; otherwise the MSC discards the termination request message. 

The MSC has to store the identity of the calling service subscriber and to check it against the identity of the service 
subscriber which sends the voice group call termination request. If they are equal, the MSC shall accept the termination 
request and release all resources. On the radio interface a channel release message shall be sent on the FACCH of all 
cells in the group call area and then all resources are freed. 

1 1 .3.2.2 Call termination by dispatchers 

A dispatcher entitled to terminate the call can be a mobile subscriber or a fixed line subscriber. The dispatcher may use 
out-of-band DTMF messages as a means for the control of the call termination, if it is a mobile dispatcher, or DTMF 
tones, if it is a fixed line dispatcher. 
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If the call is terminated by a mobile dispatcher using DTMF, the out-of-band messages START_DTMF(X) and 
STOP_DTMF are sent via the radio interface towards the network. If the out-of-band DTMF messages are sent by a 
mobile dispatcher who is not controlled by the anchor MSC, the DTMF messages will be converted by the controlling 
MSC (e.g. relay MSC or visited MSC) into DTMF tones and these DTMF tones will be sent through the network to the 
anchor MSC. 

If a fixed dispatcher initiates DTMF tones, the DTMF tones will be sent through the network to the anchor MSC. 

Both in case of a mobile and a fixed line dispatcher the anchor MSC is responsible for the detection and collection of 
the out-of-band or in-band DTMF signals. After the evaluation of the DTMF signals, the anchor MSC shall trigger the 
appropriate function (see the figures 7b to 7d in 11.3.8). 

In order to avoid the erroneous detection of the specific DTMF tone sequence for call termination by the MSC, this 
sequence shall consist of at least three DTMF digits. 

1 1 .3.2.3 Call termination on expiry of no activity timer 

A time-out mechanism is required such that, if the anchor MSC does not detect any activity (as specified in subclause 
8.1.2.3) within a pre-set time, the call is terminated by the anchor MSC. For this a timer shall be provided with a length 
as defined in the group call attributes in the GCR. 

The network may provide an in-band indication, e.g. a tone, to inform the participants of the group call about the 
forthcoming expiry of the "no activity" timer. 

1 1 .3.3 Leaving of a dispatcher 

A dispatcher can disconnect from the call at any time without terminating the call. In order to terminate the call a 
dispatcher who is entitled to do this must use the explicit signalling described in subclause 11.3.2.2. 

1 1 .3.4 Leaving and returning to a voice group call 

A service subscriber shall automatically disconnect from the call when leaving the group call area. 

A service subscriber shall be able to disconnect from the voice group call by a de-selection/re-selection process. 

A mobile station shall leave the voice group call by no longer listening to the voice group call downlink and returning to 
idle mode. A voice group call is returned to by listening to the periodic notification messages for that call, and reacting 
on them appropriately. 

11.3.5 Cell change 

1 1 .3.5.1 Listening subscriber 

In all cases change of cell shall be initiated and performed by the service subscriber's mobile station. In order for the 
service subscribers changing from one cell to another within the group call area a cell list for the neighbouring cells 
belonging to this group call area is periodically broadcast on the downlink S ACCH of the voice group call. In this case, 
mobile stations entering a new cell shall perform cell change according to the algorithm C2, see 3GPP TS 45.008 and 
3GPPTS 43.022. 

Mobile stations which want to enter a cell shall listen to the BCCH and to the NCH to determine which channel they 
shall retune to so that they can continue with the voice group call if available in that cell. 

NOTE: Mobile stations may require an additional receiver to read the BCCH and NCH of the neighbour cells in 
order to ensure a higher probability of receiving the relevant messages without degradation of the 
received speech quality. The additional receiver may be the same as used in subclause 11.3.1.3. 

Mobile stations entering a new location area shall perform location updating as normal. 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 40 ETSI TS 143 068 V9.2.0 (2010-10) 

1 1 .3.5.2 Talking subscriber 

Standard mobile station assisted handover shall be used for the cell change of the talking service subscriber as defined 
in 3GPPTS 45.008. 

If the "talker channel parameter" indicates that the network shall always establish and maintain a dedicated channel for 
the talking service subscriber, the channel allocated by the network in the target cell shall always be a dedicated 
channel. 

If the network supports uplink access option (i) as defined in subclause 7.2, collision cases between a handover of the 
talking service subscriber to a voice group call channel and an uplink access message on the same group call channel 
uplink shall be treated in the following way: 

- when the BSS allocates the handover resources for the talking service subscriber, the BSS shall send an updated 
UPLINK BUSY message in the target cell and no longer accept uplink access messages on this group call 
channel uplink ; 

- when the BSS already granted the uplink to another subscriber , the BSS shall delay the resource allocation for 
the handover of the current talker to the same cell. If the MSC accepts the uplink request for the new talker , the 
BSS shall cancel the handover resource allocation . Additionally, if the current talker is served by the BSS, the 
BSS shall release the current talker. Otherwise, if the MSC does not accept the uplink request for the new talker, 
the BSS shall release the new talker and proceed with the handover of the current talker. 

If the talking subscriber leaves the group call area or enters a BSC area not belonging to the service area, the uplink 
shall not be maintained by the network. 

If the BSS does not know if one or more of the target cells are outside the group call area, the BSS shall use the MSC 
controlled handover procedure. The MSC shall reject the handover in the case that all target cells are outside the GCA 
and as an option release the uplink. 

In a RANflex configuration, if the target cell belongs to a location area for which the group call serving MSC is not the 
old cell's serving MSC, an inter MSC handover shall be performed. 

1 1 .3.5.3 Dispatcher 

Dispatchers which are mobile subscribers shall change the cell by standard handover procedures. 

11.3.6 New calls 

Any service subscriber originated new voice group calls which have identical group ID and group call area to on-going 
voice group calls shall be rejected by the network with cause busy. The mobile station shall then read the notifications 
for the corresponding group ID on the NCH. 

For any dispatcher originated new voice group calls which are identical to on-going voice group calls as described 
above the network shall include the dispatcher in the on-going call. 

Otherwise, new calls are treated as detailed in subclause 11.3.8. In the case of congestion, voice group calls are treated 
according to their priority with each BSC treating each downlink depending on the situation in each cell to which the 
call is sent. Therefore, it is possible that a voice group call might be established only in a subset of the required cells. 

In the case where there are no conference bridges free, and pre-emption is not performed, then the call request shall be 
rejected. 

In the case of group members involved in group or point-to-point calls who have been informed of a new voice group 
call, the mobile station shall make a decision as to which to monitor as if both the on-going call and new call were 
point-to-point calls, and follow the procedure defined in 3GPP TS 23.067. 

1 1 .3.7 Uplink and Downlink management 
1 1 .3.7.1 Uplink transmission management 

The downlink FACCH channel shall be used to indicate whether the uplink is in use. 
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If a request to talk is made by the user and the upHnk has been free the mobile station shall start to transmit 
UPLINK_ACCESS messages as defined in the 3GPP TS 44.018. 

If the network supports the use of talker priorities, a mobile station supporting the use of talker priorities may 

- send a request to talk even if an uplink busy indication is received, if the talker priority of the new request is 
higher than the talker priority of the current talking service subscriber; or 

send an emergency mode reset request, if the emergency mode indication is signalled by the network. 

If a VGCS_UPLINK_GRANT message is received by the mobile station with a different request reference than that of 
the access made by the mobile station, the mobile station shall not signal for a further 1 s. 

If in this time the uplink becomes busy, and the network does not support the use of talker priorities, the mobile station 
shall indicate to the user that the access has been denied. 

If in this time the uplink becomes busy, and the network indicates in the UPLINK_BUS Y message a talker priority 
equal or higher than the talker priority used by the mobile station in the UPLINK_ACCESS message or 
PRIORITY_UPLINK_REQUEST message, the mobile station shall indicate to the user that the access has been denied; 
otherwise, it shall resend the UPLINK_ACCESS message or PRIORITY_UPLINK_REQUEST message, respectively. 

The user shall be provided with a short indication immediately after the reception of the VGCS_UPLINK_GRANT 
which indicates that he can speak. Contention caused by simultaneous access messages on the uplink of the voice group 
call channel shall be resolved as for standard random access procedures. If the uplink access is rejected a further 
indication shall be provided to the user to inform him that his access attempt was not successful. 

The network then shall send an UPLINK_BUS Y message on the FACCH of the voice group call channel downlink in 
all cells involved in the group call. 

Signalling messages for call establishment and termination on the voice group call channel shall then only apply for the 
mobile station currently using the uplink. All other mobile stations shall not respond to this downlink signalling. Once 
the request to talk is over, this shall be indicated to the network by the mobile station, an UPLINK_FREE message is 
broadcast on all FACCHs in the group call area. 

If the network supports the use of talker priorities, the BSS shall include the priority of the current talker in the 
UPLINK_BUSY message and shall repeat the message on the FACCH every Tl seconds. 

If the network supports uplink access option (i) as defined in subclause 7.2, the BSS shall indicate in the 
UPLINK_BUSY message which channel shall be used by service subscribers for an uplink request in the current cell. 
The UPLINK_BUS Y message can contain two different indications. The mobile station of the service subscriber shall 
act: 

according to the "uplink access indication for talker priority" when signalling an uplink request with talker 
priority higher than "normal subscriber" or an "emergency mode reset request; or 

- according to the "uplink access indication for data" when signalling an uplink request for sending application- 
specific data. 

If both indications are included in the UPLINK_BUS Y message, they should be set to the same value. 

If the "talker channel parameter" is used and indicates that the network shall always establish and maintain a dedicated 
channel for the talking service subscriber, then the BSS shall set any uplink access indication included in the uplink 
busy message (i.e. "uplink access indication for data", "uplink access indication for talker priority", or both) to "group 
call channel uplink access". 

Otherwise, the BSS shall apply the following procedures: 

If the talking service subscriber uses the group call channel uplink in the current cell, the BSS shall indicate in 
the UPLINK_BUSY message that the RACH shall be used; otherwise it shall indicate that the group call channel 
uplink shall be used. The BSS shall immediately send an updated UPLINK_BUSY message: 

- in the handover target cell when the BSS allocates the resources for a handover of the talking service 
subscriber to the voice group call channel in the target cell; 

- in the handover target cell when BSS releases the resources allocated for the handover of the talking service 
subscriber to the voice group call channel in the target cell, because handover failed; 
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- in the handover source cell after reception of a HANDOVER SUCCEEDED message; 

in the current cell after the talking service subscriber has been switched within the cell from the group call 
channel to a dedicated channel or vice versa. 

When the BSS receives an indication from the MSC that the emergency mode is set in the network, the BSS shall 
immediately send an UPLINK_BUSY message on the FACCH and include also the "emergency mode indication". 

If the BSS receives a VGCS Additional Info message from the MSC, an ADDITIONALJNFO message is broadcasted 
on the FACCHs of the voice group call channel downlink in all cells involved in the current group call. If the BSS 
receives the additional information in the UPLINK_SEIZED_CMD, UPLINK_REQUEST_ACKNOWLEDGE or 
UPLINK_REJECT_CMD message then the BSS may include the information in the UPLINK BUSY message instead 
of sending it in a separate ADDITION AL_INFO message on the group call channel downlink. The BSS shall repeat the 
ADDITIONAL_INFO message on the SACCHs of the respective voice group call channels every T2 seconds, until the 
uplink is released, or the BSS receives an Uplink Release Command message or Uplink Seized Command message for 
the respective voice group call from the MSC. 

If the BSS receives a VGCS Additional Info message from the MSC and the current talker on a dedicated channel is 
pre-empted by another service subscriber with a higher talker priority, the BSS shall transmit the additional information 
about the new talker also to the current talker when releasing his dedicated channel. 

1 1 .3.7.1 a Transfer of a talking service subscriber to a dedicated connection 

The network may decide to switch a talking service subscriber's mobile station from the voice group call channel to a 
dedicated standard uplink/downlink at any time. The talking subscriber's voice group call channel and the dedicated 
channel may belong to different cells within the group call area, i.e. the network may request the talker to perform a 
handover. The dedicated connection shall then be maintained up to the instance where the network decides that the 
mobile station shall join the voice group call channel again. 

If the "talker channel parameter" is used and indicates that the network shall always establish and maintain a dedicated 
channel for the talking service subscriber, a dedicated traffic channel shall be allocated to the talking service subscriber. 
If there are not sufficient radio resources to allocate a suitable dedicated channel in a cell within the group call area, the 
MSC shall release the uplink of the voice group call channel used by the talking service subscriber. 

1 1 .3.7.1 b Release of the dedicated transmission means of a talking service subscriber 

For the release of the dedicated transmission means of a talking service subscriber the procedures specified in subclause 
11.3.1.1.3 apply accordingly. 

1 1 .3.7.2 Mute/Unmute downlink of the talker 

This subclause applies to networks where the talking service subscriber may use the voice group call channel. The 
handling of the Mute/Unmute requests by the anchor MSC is shown in Figure la. 

The mobile station of the talking service subscriber shall mute the downlink to avoid non intelligible echoes when it is 
commanded by the network to mute the downlink. On request of the dispatcher, the network can command the mobile 
station of talking service subscriber to mute or unmute the downlink. 

If a dispatcher originates a VGCS call, he is allowed to talk immediately when the VGCS call is established. If a 
dispatcher joins or re-joins an ongoing VGCS call, he is allowed to talk to the ongoing VGCS call at any time without 
need to indicate this by any kind of signalling. If there is a talking service subscriber using the uplink of the group call 
channel, he will not be able to hear the dispatcher's voice. 

If a dispatcher wishes to talk to the talking service subscriber and all members of the ongoing group call, he shall 
indicate his wish by means of an operator-defined operation (via DTMF). If the dispatcher has finished speaking, he 
shall indicate this by means of another operator defined operation (via DTMF). These operations will trigger the 
network to command the talking service subscriber's MS to mute or unmute the downlink of voice group call channel. 

When the network has detected a valid unmute request from a dispatcher it may optionally indicate the recognition of 
this request by playing a "grant tone" to be received by the requesting dispatcher only. The grant tone will be sent in- 
band. The attributes of the grant tone (e.g. frequency and duration) are network operator specific. 
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A dispatcher can be a mobile subscriber or a fixed line subscriber. The dispatcher uses out-of-band DTMF messages if 
it is a mobile dispatcher, or DTMF tones, if it is a fixed line dispatcher. In case of a mobile dispatcher, the out-of-band 
messages START_DTMF(X) and STOP_DTMF are sent via the radio interface towards the network. If the out-of-band 
DTMF messages are sent by a mobile dispatcher who is not controlled by the anchor MSC, the DTMF messages will be 
converted by the controlling MSC (e.g. visited MSC) into DTMF tones and these DTMF tones will be sent through the 
network to the anchor MSC. If a fixed line dispatcher initiates DTMF tones, the DTMF tones will be sent through the 
network to the anchor MSC. 

NOTE: The transport of DTMF tones within the network is detailed in figures 7b, 7c and 7d. 

Both for mobile and fixed line dispatchers the anchor MSC is responsible for the detection and collection of the out-of- 
band or inband DTMF signals. After the evaluation of the DTMF signals, the anchor MSC shall trigger the appropriate 
action (i.e. send/not send the SET_PARAMETER message according to previous paragraphs, playing of the optional 
grant tone). 

The DTMF sequences used for signalling are implementation specific. These two DTMF sequences shall not be the 
same. 
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Figure 1a: Handling of Mute/Unmute Requests in Anchor MSC (Sheet 1 of 3) 
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Figure 1a: Handling of Mute/Unmute Requests in Anchor MSC (Sheet 2 of 3) 
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Figure la: Handling of Mute/Unmute Requests in Anchor MSC (Sheet 3 of 3) 
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Figure 1b: Handling of Mute/Unmute Requests in Relay MSC (Sheet 1 of 2) 
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Figure 1b: Handling of Mute/Unmute Requests in Relay MSC (Sheet 2 of 2) 
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1 1 .3.7a Signalling procedures for the user plane 
1 1 .3.7a.1 Group call re-establishment by the BSS 

The MSC and BSC negotiate during the setup of a voice group call whether "group call re-establishment by the BSS" is 
supported by both entities. 

If "group call re-establishment by the BSS" is supported by both entities or the network uses a transmission architecture 
with A-interface link sharing, the following procedures apply: 

i) If the BSS needs to release the group call channel in a cell due to an equipment failure or another BSS-generated 
reason (e.g. preemption), the BSS shall inform the MSC of the failure with either: 

- Uplink Release Indication and VGCS Assignment Status message if the group call channel is serving the 
current talker; or 

- VGCS Assignment Status message if the group call channel is not serving the current talker. 

The terrestrial resource for the group call channel is not released by the MSC. 

ii) When the condition that caused the failure is subsequently removed, the BSS shall re-allocate a radio resource 
for the group call channel and inform the MSC of the recovery with a VGCS Assignment Status message. 

iii) If A-interface link sharing is used, each of the VGCS ASSIGNMENT STATUS messages in item (i) and (ii) 
shall be sent after expiry of timer Tast. 

Otherwise, if "group call re-establishment by the BSS" is not supported by both entities and the network does not use a 
transmission architecture with A-interface link sharing, the following procedures apply: 

i) If the BSS needs to release the group call channel in a cell due to an equipment failure or another BSS-generated 
reason (e.g. preemption), the BSS shall inform the MSC of the failure with either: 

- Uplink Release Indication if the group call channel is serving the current talker; or 

- Clear Request if the group call channel is not serving the current talker. 

ii) The MSC shall then initiate the clearing of the radio and terrestrial resources for the group call channel. If 

supported, the MSC may retry the VGCS Assignment procedure for the cell, depending on the reason for release. 

Group call re-establishment by the BSS does not apply to the dedicated link of the talker. If the BSS needs to release the 
dedicated channel of the talker due to an equipment failure or another BSS-generated reason (e.g. preemption), the BSS 
shall inform the MSC of the failure with an Uplink Release Indication. The MSC shall then initiate the clearing of the 
radio and terrestrial resources for the dedicated channel. 

1 1 .3.8 Overview of signalling 

In this overview, the messages required to implement the specified concept are identified, and brief details are given of 
each message. 

A diagrammatic representation of the voice group call message structure proposed and actions required are given in 
figures 2 to 7d. 

Summary of figures in this subclause: 

Figure 2: voice group call establishment by a service subscriber roaming in the anchor MSC area; 

Figure 3: voice group call establishment by a service subscriber roaming in the relay MSC area; 

Figure 3a: voice group call establishment by a service subscriber in a RANflex configuration; 

Figure 3b: voice group call establishment by a mobile dispatcher of fixed line dispatcher; 

Figure 4: uplink access request in the anchor MSC area without talker priority (uplink free); 
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Figure 4a: uplink access request in the anchor MSC area with talker priority "privileged subscriber" (uplink free, 
subsequent talker on dedicated channel); 

Figure 4b: uplink access request in the anchor MSC area with talker priority "emergency subscriber" (uplink busy, 
access via group call channel uplink, subsequent talker on dedicated channel); 

Figure 4c: uplink access in the anchor MSC area with "emergency mode reset request" (uplink busy, access via group 
call channel uplink); 

Figure 4d: uplink access request in the anchor MSC area with talker priority "privileged subscriber" (uplink busy, access 
via RACH, subsequent talker on group call channel uplink); 

Figure 4e: uplink access in the anchor MSC area with "emergency mode reset request" (uplink busy, access via RACH); 

Figure 5: uplink access request in the relay MSC area without talker priority (uplink free); 

Figure 5a: uplink access request in the relay MSC area with talker priority "privileged subscriber" (uplink busy, access 
via RACH, subsequent talker on group call channel uplink); 

Figure 5b: dispatcher indicates wish to speak, talker attached to the anchor MSC; 

Figure 5c: dispatcher indicates wish to speak, talker attached to the relay MSC; 

Figure 5d: mobile dispatcher roaming in a non- Anchor MSC area indicates wish to speak, talker attached to the anchor 
MSC; 

Figure 6: uplink release requested by the network; 

Figure 6a: uplink release requested by the network; preemption of the current talker by a privileged talker; 

Figure 6b: uplink release, talker on a dedicated link (normal case); 

Figure 6c: uplink release, talker on a dedicated link (loss of radio contact or equipment failure (TRX, PCM, ...)); 

Figure 6d: uplink release, talker on group call channel (normal case); 

Figure 6e: uplink release, talker on group call channel (loss of radio contact); 

Figure 6f: uplink release, talker on group call channel (equipment failure (TRX, PCM, ...)), group call re-establishment 
by the BSS not supported; 

Figure 6g: release after equipment failure (TRX, PCM, . . .) concerning a cell not serving the talker, group call re- 
establishment by the BSS not supported; 

Figure 6h: A-interface link sharing used or group call re-establishment by the BSS supported: Uplink release for the 
talker on group call channel after equipment failure (TRX, PCM . . .) 

Figure 6i: A-interface link sharing used or group call re-establishment by the BSS supported: Release after equipment 
failure (TRX, PCM, . . .) concerning a cell not serving the talker; 

Figure 6j: A-interface link sharing used or group call re-establishment by the BSS supported: Release after equipment 
failure concerning the link between MSC and BSS; 

Figure 7: termination of the group call by the calling service subscriber; 

Figure 7a: voice group call establishment by a service subscriber using immediate setup; 

Figure 7b: signalling for DTMF digit entry by an entitled mobile dispatcher controlled by the anchor MSC; 

Figure 7c: signalling for DTMF digit entry by an entitled mobile dispatcher controlled by a visited MSC; 

Figure 7d: signalling for DTMF digit entry by an entitled fixed line dispatcher; 

Figure 7e: Validation of Priority Uplink Requests for a ciphered group call; 

Figure 7f: A listener in the anchor MSC area sends application-specific data to the other group call members, while the 
group call channel uplink in the cell is free; 
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Figure 7g: A talker in the anchor MSC area sends appHcation- specific data to the other group call members; 

Figure 7h: A listener in a relay MSC area sends application-specific data to the other group call members, while the 
group call channel uplink in the cell is free; 

Figure 7i: After receiving application-specific data, a service subscriber in the anchor MSC area sends a confirmation 
for the received data to the other group call members, while the group call channel uplink in the cell is free; 

Figure 7j: A listener in the anchor MSC area sends application- specific data that is not time-critical via RACH to the 
other group call members, while the talker is using the group call channel uplink in the same cell. 
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NOTE: MS' = calling service subscriber mobile station; 

MSs = destination service subscriber mobile stations; 

FNT = fixed network user terminal; 

MSC-A = anchor MSC; 

MSC-R = relay MSC. 

Figure 2: Signalling information required for establishing voice group calls 
by a service subscriber roaming in the anchor MSC area 

SYSJNFO (NCH allocated): Message used to indicate if the NCH is allocated on the CCCH in the cell. 
Initial RACH CHAN_REQ: Standard message. 
IMM_ASS: Standard message sent on the AGCH. 

SERV_REQ (voice group call): Modified form of the current call request message L3-MM CM SERVICE REQUEST 

sent on the allocated channel. Teleservice Voice group call is indicated. 

UA (SERV_REQ): This message is used to acknowledge the layer 2 link and provide contention resolution of the 
service request. 

COM_L3_INFO: The MSC is provided with initial information about the voice group call. 

NOTE 1: Messages flows for authentication and ciphering are not represented although performed as normal. 

PROC_ACC_REQ: The MAP_PROCESS_ACC_REQ message is sent to the VLR to check the requested VGCS 
teleservice against the subscription data. 

PROC_ACC_ACK: The MAP_PROCESS_ACC_ACK message acknowledges the requested service. 

Authentication and Ciphering: Authentication and Ciphering may be performed. Acknowledgement of the service 
request can also be performed by sending the CM SERVICE ACCEPT. 

SETUP: The MSC is provided with details about the voice group call. Optionally this message may contain a talker 
priority. 

NOTE 2: Alternatively, an IMMEDIATE_SETUP may have been send as the initial message including all details 
of the voice group call. In this case no SETUP message must be sent. 

SEND_INFO_OUT: The requested group ID is transferred to the VLR in the 
MAP_SEND_INFO_FOR_OUTGOING_CALL message. 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 52 ETSI TS 143 068 V9.2.0 (2010-10) 

COMPLETE_CALL: The VLR returns the MAP_COMPLETE_CALL message confirming the use of the requested 
group ID. The VLR also returns additional information about the calling service subscriber, if available. 

GCRJNT: The group call attributes are requested from the GCR through the GCR Interrogation message sent by the 
MSC. 

GCR_INT_ACK: The requested information is returned from the GCR in the GCR Interrogation Ack message. 

ASSIGNMENT_REQUEST: Standard message. 

CHAN_MOD_MODFY: Standard message to modify the channel mode in case of very early assignment. 

CHAN_MOD_MODFY_ACK: Standard message to acknowledge the modification of the channel mode. 

ASSIGNMENT_COMPLETE: Standard message. 

NOTE 3: Alternatively, early assignment or OACSU procedures might be applied with the corresponding 
assignment messages not presented in figure 2. 

VGCS_SETUP: This message is sent from the MSC to all affected BSCs, [one dedicated message for each BSC,] 
including the group call reference with the eMLPP priority, and optionally the call priority. 

VGCS_SETUP_ACK: Acknowledgement message from the affected BSC in answer to the VGCS_SETUP message. If 
the setup is not successful, a VGCS_SETUP_REFUSE message shall be sent instead. 

VGCS_ASSIGNMENT_REQ: This message is sent from the MSC to all affected BSCs, [one dedicated message for 
every requested channel in a cell] including the group call reference, the channel type and possibly the call priority and 
details on the ciphering. 

NOTE 4: As an operator option the voice group call channels, the links to them and optionally also the links to 
dispatchers can already be established and permanently reserved in order to speed up the call set-up for 
emergency voice group calls. 

In case of A-interface link sharing this message shall contain a list of all cells in the group call area served by this BSC. 
If the entire list of cell identifiers does not fit into the message, one or more VGCS AREA CELL INFO messages with 
additional cell identifier lists shall be sent. If the cell of origin is served by this BSC, the cell shall be included in the 
VGCS ASSIGNMENT REQUEST message. 

VGCS_AREA_CELL_INFO: This message shall contain the cell IDs that did not fit into the VGCS ASSIGNMENT 
REQUEST message in case of A-interface link sharing. 

VGCS_ASSIGNMENT RESULT: Acknowledgement message from the affected BSC in answer to the assignment 
requests. If the assignment is not successful, a VGCS_ASSIGNMENT_FAILURE message shall be sent instead. 

In case of A-interface link sharing this message shall be sent as soon as a channel could be established to the cell of 
origin or, if the cell of origin is not served by this BSC, to any other cell. Then timer Tast shall be started. 

Tast: In a network supporting A-interface link sharing timer Tast shall be used to measure the duration between 
periodic reports from the BSC to the MSC of Group Call Area cells for which channels have been assigned or released 
since the last periodic report. When timer Tast expires, if new cells in the Group Call Area have been established or 
existing ones have been released, pre-empted or failed, the MSC shall be informed of the changes (see subclause 7.1b). 
Timer Tast shall be started again to measure the period of time until the next report. The timer shall be stopped when 
the call is released. 

VGCS_ASSIGNMENT_STATUS: This message shall be sent in case of A-interface link sharing from the BSC to 
inform the MSC about the status of the channel establishment to the cells of a given VGCS call. This message shall be 
sent after timer Tast expires and new channels are established or existing channels were released, pre-empted or failed. 
This message shall also be immediately sent, and Tast restarted, when all cells for a given group call area served by the 
BSC are established, indicating this. 

SETUP to fixed network users: Based on the information determined about the users of external networks to be 
involved in the call, the MSC shall initiate calls to these users in the normal manner, depending on their mode of 
connection into the MSC, and shall connect them into the conference bridge. Alternatively normal calls to GSM 
subscribers may be established for dispatchers being GSM subscribers which are not presented in the diagram. 
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PREP ARE_GROUP_C ALL: The group call attributes are sent to every relay MSC and a Group Call number for call 
set-up to is requested. 

PREPARE_GROUP_CALL_ACK: The Group Call number for call set-up is returned to the anchor MSC. 

SETUP to MSC-R: The ISUP connection is set-up to the relay MSC. 

CONNECT from MSC-R: Set-up of the ISUP connection to the relay MSC is confirmed. 

SEND_GROUP_CALL_END_SIGNAL: Indicates to the anchor MSC that at least one voice group call channel has 
been established in the relay MSC area. 

FORWARD_GROUP_CALL_SIGNALLING (IMSI, additional info): The IMSI of the service subscriber who has 
established the voice group call and who is allowed to terminate the call is sent to every relay MSC. If the network 
supports the use of talker priorities, the message includes also the talker priority. Furthermore, the message provides 
additional information about the current talking service subscriber, if available. 

Txx: Timer implemented in the MSC which is started with receipt of the SETUP message from the calling service 
subscriber. If the timer expires before the conditions for establishment have been met, as per subclause 11.3.1.1.2, then 
the call shall be released. 

NOTIF_REQ (NCH): Messages for notification which contain the group call reference, the priority of the call if 
eMLPP is applied, and possibly the channel description of the voice group call channel to which the mobile stations 
shall listen and the number of the group key used for ciphering. 

NOTIF_REQ (FACCH): Message for notification sent on the FACCH to the mobile stations currently involved in 
other calls. The notification on the FACCH shall include the group call reference, and the priority level and may also 
include the channel description and the group ciphering key numbers. 

UPLINK_SEIZED_CMD: If the network supports the use of talker priorities, this message informs the BSS about the 
talker priority of the current talking service subscriber and about the status of the emergency mode. The MSC may also 
include additional information about the current talking service subscriber, if the information is available when sending 
this message. 

UPLINK_BUSY: If the network supports the use of talker priorities, this connectionless RR message is sent on the 
downlink FACCH to inform all mobile stations about the talker priority of the current talking service subscriber and 
about the status of the emergency mode. The network may also include additional information about the current talking 
service subscriber, if the information is available when sending this message and there is sufficient space available in 
the message. The message is repeated on the FACCH every Tl seconds. 

VGCS_ADD_INFO: The MSC sends additional information about the current talking service subscriber to all BSCs, 
unless the information was already included in the UPLINK_SEIZED_CMD message. 

ADDJNFO: The BSCs broadcast the additional information on the FACCH to all listeners. , unless the information 
was already included in the UPLINK_BUSY message 

Periodic ADD_ INFO (SACCH): The message is repeated on the SACCH every T2 seconds. 

Periodic NOTIF_REQ (NCH): The notifications are sent periodically so that mobile stations moving into the area can 
join the voice group call. 

Periodic SACCH Info: Periodic messages sent on SACCH. This message may include: 

- information of changes of notifications; 

information used for cell re- selection. 

CONNECT: Information to the mobile station of the calling service subscriber that the VGCS is established with the 
related group call reference as the connected number. The CONNECT message is sent as soon as conditions for 
establishment are met, as per subclause 11.3.1.1.2. If the SETUP message from the calling subscriber contained a talker 
priority, the MSC returns the talker priority used by the network. This will be lower than the requested talker priority, if 
the subscription check for the requested talker priority was unsuccessful. 

UPLINK_RELEASE: When the calling service subscriber wants to become a listening service subscriber for the first 
time, a message indicating release of the uplink is required to be sent from the MS to the BSS in order to set the uplink 
free. 
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NOTE 4a: For different cases of uplink release and the related message flows refer to Figure 6.b to 6.g. 

UPLINK_RELEASE_INDICATION: The BSS informs the MSC on the upHnk release. 

FORWARD_GROUP_CALL_SIGNALLING (uplink release indication): This message is sent to every relay MSC 
to indicate that the uplink is free. 

CLEAR COMMAND : The MSC requests the BSS to clear radio and terrestrial resources associated with originator 
dedicated link if not already done. 

CHAN_RELEASE: The BSS sends a channel release message to the calling service subscriber's mobile station 
including the channel description of the voice group call channel to which the mobile station shall tune to. 

NOTE 5: Alternatively, if no UPLINK_RELEASE has been sent to the network by the mobile station, the network 
may transfer the mobile station to the voice group call channel by the channel mode modify procedure or 
by an assignment procedure or by a handover procedure. 

DISC: Two layer 2 disconnect messages shall be sent by the mobile station to the network. 
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Figure 3: Signalling information required for establishing voice group calls 
by a service subscriber roaming in the relay MSC area 

SYSJNFO (NCH allocated): Message used to indicate if the NCH is allocated on the CCCH in the cell. 
Initial RACH CHAN_REQ: Standard message. 
IMM_ASS: Standard message sent on the AGCH. 

SERV_REQ (voice group call): Modified form of the current call request message L3-MM CM SERVICE REQUEST 

sent on the allocated channel. Teleservice Voice group call is indicated. 

UA (SERV_REQ): This message is used to acknowledge the layer 2 link and provide contention resolution of the 
service request. 

COM_L3_INFO: The MSC is provided with initial information about the voice group call. 

NOTE 6: Messages flows for authentication and ciphering are not represented although performed as normal. 

PROC_ACC_REQ: The MAP_PROCESS_ACC_REQ message is sent to the VLR to check the requested VGCS 
teleservice against the subscription data. 

PROC_ACC_ACK: The MAP_PROCESS_ACC_ACK message acknowledges the requested service. 

Authentication & Ciphering: Authentication and Ciphering may be performed. Acknowledgement of the service 
request can also be performed by sending the CM SERVICE ACCEPT. 

SETUP: The MSC is provided with details about the voice group call. Optionally this message may contain a talker 
priority. 

NOTE 7: Alternatively, an IMMEDIATE_SETUP may have been send as the initial message including all details 
of the voice group call. In this case no SETUP message must be sent. 

SEND_INFO_OUT: The requested group ID is transferred to the VLR in the 
MAP_SEND_INFO_FOR_OUTGOING_CALL message. 

COMPLETE_CALL: The VLR returns the MAP_COMPLETE_CALL message confirming the use of the requested 
group ID. The VLR also returns additional information about the calling service subscriber, if available. 

GCRJNT: The group call attributes are requested from the GCR through the GCR Interrogation message sent by the 
MSC. 

GCR_INT_ACK: The requested information (MSC-A address) is returned from the GCR in the GCR Interrogation 
Ack message. 

ASSIGNMENT_REQUEST: Standard message. 

CHAN_MOD_MODFY: Standard message to modify the channel mode in case of very early assignment. 

CHAN_MOD_MODFY_ACK: Standard message to acknowledge the modification of the channel mode. 

ASSIGNMENT_COMPLETE: Standard message. 
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NOTE 8: Alternatively, early assignment or OACSU procedures might be applied with the corresponding 
assignment messages not presented in figure 3. 

SETUP to MSC-A: Based on information received from the GCR the relay MSC shall set-up a dedicated connection 
for the calling service subscriber to the anchor MSC. The address of the calling service subscriber's relay MSC shall be 
sent as calling party number. 

PREP ARE_GROUP_C ALL: The group call attributes (parts) are received from the anchor MSC. 

GCRJNT: The group call attributes are requested from the GCR through the GCR Interrogation message sent by the 
MSC. 

GCR_INT_ACK: The requested information (cell list) is returned from the GCR in the GCR Interrogation Ack 
message. 

ALLOCATE GROUP CALL NUMBER: The Group Call number is requested from the VLR. 

ALLOCATE GROUP CALL NUMBER ACK: The Group Call number is returned from the VLR. 

PREPARE_GROUP_CALL_ACK: The Group Call number is sent to MSC-A. 

SETUP from MSC-A: The ISUP connection is set-up between MSC-A and MSC-R. 

RELEASE GROUP CALL NUMBER: The VLR is requested to release the Group Call number. 

VGCS_SETUP: This message is sent from the MSC to all affected BSCs, [one dedicated message for each BSC,] 
including the group call reference with the eMLPP priority, and optionally the call priority. 

VGCS_SETUP_ACK: Acknowledgement message from the affected BSC in answer to the VGCS_SETUP setup 
message. If the setup is not successful, a VGCS_SETUP_REFUSE message shall be sent instead. 

VGCS_ASSIGNMENT_REQ: This message is sent from the MSC to all affected BSCs, [one dedicated message for 
every requested channel in a cell,] including the group call reference, the channel type and possibly the call priority and 
details on the ciphering. 

NOTE 9: As an operator option the voice group call channels, the links to them and optionally also the links to 
dispatchers can already be established and permanently reserved in order to speed up the call set-up for 
emergency voice group calls. 

In case of A-interface link sharing this message shall contain a list of all cells in the group call area served by this BSC. 
If the entire list of cell identifiers does not fit into the message, one or more VGCS AREA CELL INFO messages with 
additional cell identifier lists shall be sent. If the cell of origin is served by this BSC, the cell shall be included in the 
VGCS ASSIGNMENT REQUEST message. 

VGCS_AREA_CELL_INFO: This message shall contain the cell IDs that did not fit into the VGCS ASSIGNMENT 
REQUEST message in case of A-interface link sharing. 

VGCS_ASSIGNMENT_RESULT: Acknowledgement message from the affected BSC in answer to the assignment 
requests. If the assignment is not successful, a VGCS_ASSIGNMENT_FAILURE message shall be sent instead. 

In case of A-interface link sharing this message shall be sent as soon as a channel could be established to the cell of 
origin or, if the cell of origin is not served by this BSC, to any other cell. Then timer Tast shall be started. 

Tast: In a network supporting A-interface link sharing timer Tast shall be used to measure the duration between 
periodic reports from the BSC to the MSC of Group Call Area cells for which channels have been assigned or released 
since the last periodic report. When timer Tast expires, if new cells in the Group Call Area have been established or 
existing ones have been released, pre-empted or failed the MSC shall be informed of the changes (see subclause 7.1b). 
Timer Tast shall be started again to measure the period of time until the next report. The timer shall be stopped when 
the call is released. 

VGCS_ASSIGNMENT_STATUS: This message shall be sent in case of A-interface link sharing from the BSC to 
inform the MSC about the status of the channel establishment to the cells of a given VGCS call. This message shall be 
sent after timer Tast expires and new channels are established or existing channels are released, pre-empted or failed. 
This message shall also be immediately sent, and Tast restarted, when all cells for a given group call area served by the 
BSC are established, indicating this. 
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CONNECT to MSC-A: Set-up of the ISUP connection from the anchor MSC is confirmed. 

SEND_GROUP_CALL_END_SIGNAL (IMSI, additional info): Indicates to the anchor MSC that conversation can 
start. In addition the IMSI of calHng service subscriber who has established the voice group call and who is allowed to 
terminate the call is included. If the network supports the use of talker priorities, the message includes also the talker 
priority. Furthermore, the message provides additional information about the current talking service subscriber, if 
available. 

NOTIF_REQ (NCH): Messages for notification which contain the group call reference, the priority of the call if 
eMLPP is applied, and possibly the channel description of the voice group call channel to which the mobile stations 
shall listen and the number of the group key used for ciphering. 

NOTIF_REQ (FACCH): Message for notification sent on the FACCH to the mobile stations currently involved in 
other calls. The notification on the FACCH shall include the group call reference, and the priority level and may include 
also the channel description and the group ciphering key numbers. 

UPLINK_SEIZED_CMD: If the network supports the use of talker priorities, this message informs the BSS about the 
talker priority of the current talking service subscriber and about the status of the emergency mode. The MSC may also 
include additional information about the current talking service subscriber, if the information is available when sending 
this message. 

UPLINK_BUSY: If the network supports the use of talker priorities, this connectionless RR message is sent on the 
downlink FACCH to inform all mobile stations about the talker priority of the current talking service subscriber and 
about the status of the emergency mode. The network may also include additional information about the current talking 
service subscriber, if the information is available when sending this message and there is sufficient space available in 
the message. The message is repeated on the FACCH every Tl seconds. 

VGCS_ADD_INFO: The MSC sends additional information about the current talking service subscriber to all BSCs, 
unless the information was already included in the UPLINK_SEIZED_CMD message. 

ADDJNFO: The BSCs broadcast the additional information on the FACCH to all listeners, unless the information was 
already included in the UPLINK_BUSY message. 

Periodic ADD_ INFO (SACCH): The message is repeated on the SACCH every T2 seconds. 

Periodic NOTIF_REQ (NCH): The notifications are sent periodically so that mobile stations moving into the area can 
join the voice group call. 

Periodic SACCH Info: Periodic messages sent on the downlink of the SACCH informing mobile stations of: 

- information of changes of notifications; 

information used for cell re- selection. 

CONNECT (from MSC-A): Call set-up of the dedicated connection for the calling service subscriber is confirmed. 

CONNECT: Information to the mobile station of the calling service subscriber that the VGCS is established with the 
related group call reference as the connected number. The CONNECT message is sent as soon as conditions for 
establishment are met, as per subclause 11.3.1.1.2. If the SETUP message from the calling subscriber contained a talker 
priority, the MSC returns the talker priority used by the network. This will be lower than the requested talker priority, if 
the subscription check for the requested talker priority was unsuccessful. 

UPLINK_RELEASE: When the calling service subscriber wants to become a listening service subscriber for the first 
time, a message indicating release of the uplink is required to be sent from the MS to the BSS in order to set the uplink 
free. 

NOTE 9a: For different cases of uplink release and the related message flows refer to Figure 6.b to 6.g. 

UPLINK_RELEASE_INDICATION: The BSS informs the MSC on the upHnk release. 

PROCESS_GROUP_CALL_SIGNALLING (uplink release indication): To indicate to the anchor MSC that the 
uplink is free. 

CLEAR_COMMAND: The MSC requests the BSS to clear radio and terrestrial resources associated with originator 
dedicated link if not already done. 
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CHAN_RELEASE: The BSS sends a channel release message to the calling service subscriber's mobile station 
including the channel description of the voice group call channel to which the mobile station shall tune to. 

NOTE 10: Alternatively, if no UPLINK_RELEASE has been sent to the network by the mobile station, the network 
may transfer the mobile station to the voice group call channel by the channel mode modify procedure or 
by an assignment procedure or by a handover procedure. 

DISC: Two layer 2 disconnect messages shall be sent by the mobile station to the network. 

RELEASE from MSC-A: The dedicated connection for the calling service subscriber is released with cause 'normal, 
unspecified'. 
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NOTE: MS' = calling service subscriber mobile station; 

MSs = destination service subscriber mobile stations; 

MSC-A = anchor MSC; 

MSC-R = relay MSC; 

V-MSC = visited MSC 

Figure 3a: Signalling information required for establishing voice group calls 
by a service subscriber in a RANflex configuration 

SYSJNFO (NCH allocated): Message used to indicate if the NCH is allocated on the CCCH in the cell. 
Initial RACH CHAN_REQ: Standard message. 
IMM_ASS: Standard message sent on the AGCH. 

SERV_REQ (voice group call): Modified form of the current call request message L3-MM CM SERVICE REQUEST 

sent on the allocated channel. Teleservice Voice group call is indicated. 

UA (SERV_REQ): This message is used to acknowledge the layer 2 link and provide contention resolution of the 
service request. 

COM_L3_INFO: The MSC is provided with initial information about the voice group call. 

NOTE 10a: Messages flows for authentication and ciphering are not represented although performed as normal. 
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PROC_ACC_REQ: The MAP_PROCESS_ACC_REQ message is sent to the VLR to check the requested VGCS 
teleservice against the subscription data. 

PROC_ACC_ACK: The MAP_PROCESS_ACC_ACK message acknowledges the requested service. 

Authentication & Ciphering: Authentication and Ciphering may be performed. Acknowledgement of the service 
request can also be performed by sending the CM SERVICE ACCEPT. 

SETUP: The MSC is provided with details about the voice group call. Optionally this message may contain a talker 
priority. 

NOTE 10b: Alternatively, an IMMEDIATE_SETUP may have been send as the initial message including all 
details of the voice group call. In this case no SETUP message must be sent. 

SEND_INFO_OUT: The requested group ID is transferred to the VLR in the 
MAP_SEND_INFO_FOR_OUTGOING_CALL message. 

COMPLETE_CALL: The VLR returns the MAP_COMPLETE_CALL message confirming the use of the requested 
group ID. The VLR also returns additional information about the calling service subscriber, if available. 

SEND_GROUP_CALL_INFO: The MSC derives from the originating cell's LAC the address of the group call 
serving MSC and sends MAP_SEND_GROUP_CALL_INFO to it, to retrieve the MSC-A address. The message may 
also contain talker priority and additional info. 

GCRJNT: The group call reference and MSC-A address are requested from the OCR through the OCR Interrogation 
message sent by the MSC. 

GCR_INT_ACK: The requested information (MSC-A address) is returned from the OCR in the OCR Interrogation 
Ack message. 

SEND_GROUP_CALL_INFO_ACK: The requested information is returned to the visited MSC. 

ASSIGNMENT_REQUEST: Standard message. 

CHAN_MOD_MODFY: Standard message to modify the channel mode in case of very early assignment. 

CHAN_MOD_MODFY_ACK: Standard message to acknowledge the modification of the channel mode. 

ASSIGNMENT_COMPLETE: Standard message. 

NOTE 10c: Alternatively, early assignment or OACSU procedures might be applied with the corresponding 
assignment messages not presented in figure 3a. 

SETUP to MSC-A: Based on information received from the group call serving MSC the VMSC shall set-up a 
dedicated connection for the calling service subscriber to the anchor MSC. The address of the calling service 
subscriber's group call serving MSC shall be sent as calling party number. 

PREPARE_GROUP CALL: The group call attributes (parts) are received from the anchor MSC. 

GCRJNT: The group call attributes are requested from the OCR through the OCR Interrogation message sent by the 
MSC. 

GCR_INT_ACK: The requested information (cell list) is returned from the OCR in the OCR Interrogation Ack 
message. 

ALLOCATE GROUP CALL NUMBER (not shown in figure 3a): MSC-R requests the group call number from its 
associated VLR 

ALLOCATE GROUP CALL NUMBER ACK (not shown in figure 3a): The Group Call number is returned from 
the VLR. 

PREPARE_GROUP_CALL_ACK: The Group Call number is sent to MSC-A. 

SETUP from MSC-A: The ISUP connection is set-up between MSC-A and MSC-R. 

RELEASE GROUP CALL NUMBER (not shown in figure 3a): The VLR is requested to release the Group Call 
number. 
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VGCS_SETUP: This message is sent from the MSC to all affected BSCs, [one dedicated message for each BSC,] 
including the group call reference with the eMLPP priority, and optionally the call priority. 

VGCS_SETUP_ACK: Acknowledgement message from the affected BSC in answer to the VGCS_SETUP setup 
message. If the setup is not successful, a VGCS_SETUP_REFUSE message shall be sent instead. 

VGCS_ASSIGNMENT_REQ: This message is sent from the MSC to all affected BSCs, [one dedicated message for 
every requested channel in a cell,] including the group call reference, the channel type and possibly the call priority and 
details on the ciphering. 

NOTE lOd: As an operator option the voice group call channels, the links to them and optionally also the links to 
dispatchers can already be established and permanently reserved in order to speed up the call set-up for 
emergency voice group calls. 

VGCS_ASSIGNMENT RESULT: Acknowledgement message from the affected BSC in answer to the assignment 
requests. If the assignment is not successful, a VGCS_ASSIGNMENT_FAILURE message shall be sent instead. 

CONNECT to MSC-A: Set-up of the ISUP connection from the anchor MSC is confirmed. 

SEND_GROUP CALL_END_SIGNAL (IMSI, additional info): Indicates to the anchor MSC that conversation can 
start. In addition the IMSI of calling service subscriber who has established the voice group call and who is allowed to 
terminate the call is included. If the network supports the use of talker priorities, the message includes also the talker 
priority. Furthermore, the message provides additional information about the current talking service subscriber, if 
available. 

NOTIF_REQ (NCH): Messages for notification which contain the group call reference, the priority of the call if 
eMLPP is applied, and possibly the channel description of the voice group call channel to which the mobile stations 
shall listen and the number of the group key used for ciphering. 

NOTIF_REQ (FACCH): Message for notification sent on the FACCH to the mobile stations currently involved in 
other calls. The notification on the FACCH shall include the group call reference, and the priority level and may include 
also the channel description and the group ciphering key numbers. 

UPLINK_SEIZED_CMD: If the network supports the use of talker priorities, this message informs the BSS about the 
talker priority of the current talking service subscriber and about the status of the emergency mode. 

UPLINK_BUSY: If the network supports the use of talker priorities, this connectionless RR message is sent on the 
downlink FACCH to inform all mobile stations about the talker priority of the current talking service subscriber and 
about the status of the emergency mode. The message is repeated on the FACCH every Tl seconds. 

VGCS_ADD_INFO: The MSC sends additional information about the current talking service subscriber to all BSCs. 

ADDJNFO: The BSCs broadcast the additional information on the FACCH to all listeners. 

Periodic ADD_ INFO (SACCH): The message is repeated on the SACCH every T2 seconds. 

Periodic NOTIF_REQ (NCH): The notifications are sent periodically so that mobile stations moving into the area can 
join the voice group call. 

Periodic SACCH Info: Periodic messages sent on the downlink of the SACCH informing mobile stations of: 

- information of changes of notifications; 

information used for cell re- selection. 

CONNECT (from MSC-A): Call set-up of the dedicated connection for the calling service subscriber is confirmed. 

CONNECT: Information to the mobile station of the calling service subscriber that the VGCS is established with the 
related group call reference as the connected number. If the SETUP message from the calling subscriber contained a 
talker priority, the MSC returns the talker priority used by the network. This will be lower than the requested talker 
priority, if the subscription check for the requested talker priority was unsuccessful. 

UPLINK_RELEASE: When the calling service subscriber wants to become a listening service subscriber for the first 
time, a message indicating release of the uplink is required to be sent from the MS to the BSS in order to set the uplink 
free. 
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NOTE lOe: For different cases of uplink release and the related message flows refer to Figure 6.b to 6.g. 

UPLINK_RELEASE_INDICATION: The BSS informs the MSC on the upHnk release. 

PROCESS_GROUP CALL_SIGNALLING (uplink release indication): To indicate to the anchor MSC that the 
uplink is free. 

CLEAR COMMAND: The MSC requests the BSS to clear radio and terrestrial resources associated with originator 
dedicated link if not already done. 

CHAN_RELEASE: The BSS sends a channel release message to the calling service subscriber's mobile station 
including the channel description of the voice group call channel to which the mobile station shall tune to. 

NOTE lOf: Alternatively, if no UPLINK_RELEASE has been sent to the network by the mobile station, the 
network may transfer the mobile station to the voice group call channel by the channel mode modify 
procedure or by an assignment procedure or by a handover procedure. 

DISC: Two layer 2 disconnect messages shall be sent by the mobile station to the network. 

RELEASE from MSC- A: The dedicated connection for the calling service subscriber is released. 
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Figure 3b: Signalling information required for establishing voice group calls 
by a mobile dispatcher or fixed line dispatcher 

SETUP: Mobile dispatcher or fixed line dispatcher sets up a VGCS call. The visited MSC or the Gateway MSC 
receives the SETUP message with details about the voice group call including the Group Call Reference within the 
MSISDN dialled by the originating dispatcher. 

SETUP (lAM): The visited MSC or the Gateway MSC sends an I AM message to the anchor MSC of the group call 
based on the called party MSISDN number. 

SETUP (Mobile dispatcher in anchor MSC area): If the originating mobile dispatcher is located in the anchor MSC 
area, the SETUP message with details about the voice group call including the Group Call Reference within the 
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MSISDN dialled by the originating dispatcher is received directly by the anchor MSC (further messages regarding the 
standard SETUP procedure are not drawn in the Fig.) 

SEND_INFO_OUT: The requested group ID is transferred to the VLR in the internal 
MAP_SEND_INFO_FOR_OUTGOING_CALL message. 

COMPLETE_CALL: The VLR returns the MAP_COMPLETE_CALL message confirming the use of the requested 
group ID. 

GCRJNT: The group call attributes are requested from the GCR through the OCR Interrogation message sent by the 
MSC. 

GCR_INT_ACK: The requested information is returned from the GCR in the GCR Interrogation Ack message. 

VGCS_SETUP: Anchor MSC sends to BSS's a VGCS SETUP message across VGCS call controlling SCCP 
connection to initiate a VGCS call set-up procedures. 

VGCS SETUP ACK: After receiving the VGCS_SETUP message, BSS will allocate resources to the call and returns 
VGCS SETUP ACK message to the MSC. This connection is estabHshed for the Hfetime of the VGCS call. 

VGCS_ASSIGNMENT_REQ: This message is sent from the MSC to all affected BSCs, [ including the group call 
reference, the channel type and possibly the call priority and details on the ciphering. 

PREPARE_GROUP CALL: The group call attributes are sent to every relay MSC and a Group Call number for call 
set-up to is requested. 

PREPARE_GROUP CALL ACK: The Group Call number for call set-up is returned to the anchor MSC. 

SETUP to MSC-R: The ISUP connection is set-up to the relay MSC. 

VGCS_SETUP: Relay MSC sends to BSS's a VGCS SETUP message to initiate a VGCS call set-up procedures. 

VGCS SETUP ACK: After receiving the VGCS_SETUP message, BSS will allocate resources to the call and returns 
VGCS SETUP ACK message to the MSC. This connection is estabHshed for the Hfetime of the VGCS call. 

VGCS_ASSIGNMENT_REQ: This message is sent from the relay MSC to all affected BSCs, [ including the group 
call reference, the channel type and possibly the call priority and details on the ciphering. 

CONNECT from MSC-R: Set-up of the ISUP connection to the relay MSC is confirmed. 

VGCS_ASSIGNMENT RESULT: Acknowledgement message from the affected BSC in answer to the assignment 
requests. If the assignment is not successful, a VGCS_ASSIGNMENT_FAILURE message shall be sent instead. 

SEND_GROUP CALL_END_SIGNAL: Indicates to the anchor MSC that at least one voice group call channel has 
been established in the relay MSC area. 

Txx: Timer implemented in the anchor MSC which is started with receipt of the SETUP message from the dispatcher. 
If the timer expires before the conditions for establishment have been met, as per subclause 11.3.1.1.2, then the call 
shall be released. 

FORWARD_GROUP CALL_SIGNALLING (uplink release indication): The anchor MSC indicates to all relay 
MSCs that the uplink is free. On receipt of the uplink free indication the relay MSC shall send an UPLINK RELEASE 
message to every BSS of the group call area to indicate that the uplink free. 

UPLINK_REL_CMD and UPLINK_FREE: After having received the VGCS SETUP ACK, the MSC sends to BSCs 
the UPLINK RELEASE CMD in order to indicate that the call has been initiated by a dispatcher. As a consequence, 
UPLINK FREE is sent on the common channel(s). Then a service subscriber can request the uplink by using Uplink 
Request procedure. 

NOTIF_REQ (NCH): Messages for notification which contain the group call reference, the priority of the call if 
eMLPP is applied, and possibly the channel description of the voice group call channel to which the mobile stations 
shall listen and the number of the group key used for ciphering. 

NOTIF_REQ (FACCH): Message for notification sent on the FACCH to the mobile stations currently involved in 
other calls. The notification on the FACCH shall include the group call reference; and the priority level and may also 
include the channel description and the group ciphering key numbers. 
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CONNECT: Information to the originating that the VGCS is estabUshed with the related group call reference as the 
connected number. 

Periodic NOTIF_REQ (NCH): The notifications are sent periodically so that mobile stations moving into the area can 
join the voice group call. 
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Figure 4: Signalling information required for the voice group call uplink access 
in the anchor MSC without talker priority (normal case, without contention resolution) 

UPLINK_FREE: This connectionless RR message is repeatedly sent by the BSS on the main signalling link (FACCH) 
to inform all mobile stations of the voice group call members that the uplink is free. 
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UPLINK_ACCESS: This is sent on the uplink of the voice group call channel using random access procedures. The 
UPLINK_ACCESS message is similar to a channel request but sent on the group call channel uplink. The establishment 
cause for subsequent talker uplink request as defined in 3GPP TS 44.018 shall be used for this purpose. The mobile 
station may send repeated UPLINK_ACCESS messages (see 3GPP TS 44.018). 

UPLINK_REQUEST: The request for the upHnk is indicated to the MSC. Only one request per BSC shall be 
forwarded. 

VGCS_UPLINK_GRANT: The reply to the uplink request sent on the voice group channel downlink containing 
information for synchronisation of the mobile station to the network and uplink access contention resolution. The 
VGCS_UPLINK_GRANT message shall therefore include a request reference (reflecting the UPLINK_ACCESS) and 
the physical information required for transmission on the voice group call channel uplink. On receipt of a 
VGCS_UPLINK_GRANT, the related mobile station can start to send speech directly. 

NOTE 11:UPLINK_FREE messages are stopped immediately. 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the uplink is now busy. 

NOTE 12: The order of UPLINK_BUS Y and SABM message is independent. 

SABM(L3msg): The layer 2 link is set up and layer 3 information on classmark and mobile station identity included. 

UA(L3msg): The layer 2 link is acknowledged and the layer 3 information reflected for contention resolution. 

UPLINK_REQUEST_ACKNOWLEDGE: The anchor MSC acknowledges the upHnk to one BSC. If upHnk requests 
have been made by more than one BSC or MSC-R, all remaining uplink requests shall be rejected by an 
UPLINK_REJECT_CMD which is not presented in figure 4. On reception of an UPLINK_REJECT_CMD the BSS 
shall send an UPLINK_REL to the related mobile station, followed by an UPLINK_BUSY to indicate to the mobile 
stations that the uplink is in use. The MSC shall send to other BSCs which did not send an uplink request an 
UPLINK_SEIZED_CMD message which is not presented in figure 4. On reception of an UPLINK_SEIZED_CMD the 
BSS shall send an UPLINK_BUSY to indicate to the mobile stations that the uplink is in use. 

FORWARD_GROUP CALL_SIGNALLING (uplink seized command): This message is sent to all relay MSCs, to 
inform all mobile stations roaming in parts of the group call area which are controlled by relay MSCs, that the uplink is 
now busy. 

UPLINK_REQUEST_CONFIRM: The BSS confirms the upHnk use to the MSC together with the mobile station 
identity. 

NOTE 12a: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done 
by means of the MAP service SEND_GROUP_CALL_INFO. 

VGCS_ADD_INFO: The MSC sends additional information about the new talking service subscriber to all BSCs. The 
BSCs broadcast ADD_INFO messages containing the additional information to all listeners (not shown in figure 4). 

FORWARD_GROUP CALL_SIGNALLING (additional info): This message is sent to all relay MSCs to provide 
information about the new talking service subscriber. 

Conversation proceeds: Once the mobile station has control of the uplink, it shall be able to communicate directly. 
The two-way nature of the conference bridge will ensure that they are already connected to all appropriate downlink 
channels. 

UPLINK_RELEASE: When the service subscriber who has access to the uplink wants to release the channel, then a 
message indicating release of the uplink is required to be sent from the MS to the BSS on the FACCH. 

NOTE 12b: For different cases of uplink release and the related message flows refer to Figure 6.b to 6.g. 

UPLINK_RELEASE_INDICATION: The BSS informs the MSC on the upHnk release. 

FORWARD_GROUP CALL_SIGNALLING (uplink release indication): The anchor MSC indicates to all relay 
MSCs that the uplink is free. On receipt of the uplink free indication the relay MSC shall send an UPLINK RELEASE 
message to every BSS of the group call area to indicate that the uplink free. 
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NOTE: The figure describes the handling, if IVISG decides to have a subsequent talker on a dedicated channel. 

Figure 4a: Signalling information required for the voice group call uplink access 

in the anchor MSC with talker priority "privileged subscriber*' (normal case, without contention 

resolution, subsequent talker on dedicated channel) 
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UPLINK_FREE: This connectionless RR message is repeatedly sent by the BSS on the main signalling link (FACCH) 
to inform all mobile stations of the voice group call members that the uplink is free. 

UPLINK_ACCESS: This is sent on the uplink of the voice group call channel using random access procedures. The 
UPLINK_ACCESS message is similar to a channel request but sent on the group call channel uplink. The establishment 
cause for a privileged subscriber request as defined in 3GPP TS 44.018 shall be used for this purpose. The mobile 
station may send repeated UPLINK_ACCESS messages (see 3GPP TS 44.018). 

VGCS_UPLINK_GRANT: The reply to the uplink request sent on the voice group channel downlink containing 
information for synchronisation of the mobile station to the network and uplink access contention resolution. The 
VGCS_UPLINK_GRANT message shall therefore include a request reference (reflecting the UPLINK_ACCESS) and 
the physical information required for transmission on the voice group call channel uplink. On receipt of a 
VGCS_UPLINK_GRANT, the related mobile station can start to send speech directly. 

NOTE 13: UPLINK_FREE messages are stopped immediately. 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the uplink is now busy. If the network supports talker priorities, then the UPLINK_BUS Y indicates the talker priority of 
the current talking service subscriber to all listening service subscribers and additionally, if the emergency mode is set 
in the network, the emergency mode indication. The message is repeated on the FACCH every Tl seconds. 

NOTE 14: The order of UPLINK_BUS Y and SABM message is independent. 
SABM(L3msg): The layer 2 link is set up and layer 3 information on classmark and mobile station identity included. 
UA(L3msg): The layer 2 link is acknowledged and the layer 3 information reflected for contention resolution. 

NOTE 15: Dedicated signalling connection on the main DCCH needs to be established. 

UPLINK_REQUEST: The request for the uplink containing the MS identity and the talker priority is indicated to the 
MSC. Only one request per BSS shall be forwarded. 

NOTE 16: As the BSS supports the use of talker priorities and receives from the MS a talker priority different from 
"normal subscriber", the BSS delays the sending of the UPLINK_REQUEST message to the MSC, until 
SABM(L3msg) with the MS identity is received from the MS. Then the BSS includes the layer 3 
message, the talker priority, and the cell identity of the cell where the UPLINK_ACCESS message was 
received in the UPLINK_REQUEST message. In this case the UPLINK_REQUEST_CONFIRM 
message may be omitted by the BSS. 

NOTE 16a: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done by 
means of the MAP service SEND_GROUP_CALL_INFO. 

UPLINK_REQUEST_ACKNOWLEDGE: The anchor MSC acknowledges the upHnk to one BSC. If upHnk requests 
have been made by more than one BSC or MSC-R, all remaining uplink requests shall be rejected by an 
UPLINK_REJECT_CMD which is not presented in figure 4a. On reception of an UPLINK_REJECT_CMD the BSS 
shall send an UPLINK_REL to the related mobile station, followed by an UPLINK_BUSY to indicate to the mobile 
stations that the uplink is in use. The MSC shall send to other BSCs which did not send an uplink request an 
UPLINK_SEIZED_CMD message which is not presented in figure 4a. On reception of an UPLINK_SEIZED_CMD the 
BSS shall send an UPLINK_BUSY to indicate to the mobile stations that the uplink is in use. 

The anchor MSC may also include additional information about the new talking service subscriber in the 
UPLINK_REQUEST_ACKNOWLEDGE, UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages, if the 
information is available when sending these messages. The BSS may include the additional information in the 
UPLINK_BUS Y messages, if the information is available when sending these messages and there is sufficient space 
available in the messages. 

FORWARD_GROUP CALL_SIGNALLING (uplink seized command, privileged subscriber, additional info): 

This message is sent to all relay MSCs, to inform all mobile stations roaming in parts of the group call area which are 
controlled by relay MSCs that the uplink is now busy for a talker with talker priority "privileged subscriber". 
Furthermore, the message provides additional information about the new talking service subscriber, if available. 

UPLINK_REQUEST_CONFIRM: The BSS confirms the upHnk use to the MSC together with the mobile station 
identity. 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 73 ETSI TS 143 068 V9.2.0 (2010-10) 

ASS_REQ: This message contains details of the resource(s) required for the dedicated connection. 

ASSIGNMENT_CMD: This message contains details of the resource(s) required and triggers the assignment 
procedure of the dedicated channel at the MS. 

ASSIGNMENT_COMP: Standard message. 

ASS_COMP: Standard message. 

VGCS_ADD_INFO: The MSC sends additional information about the new talking service subscriber to all BSCs, 
unless the information was already included in the UPLINK_REQUEST_ACKNOWLEDGE, 
UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages. The BSCs broadcast ADDJNFO messages 
containing the additional information to all listeners (not shown in figure 4a) , unless the information was already 
included in the UPLINK_BUSY messages. 

Conversation proceeds: Once the mobile station has control of the uplink, it shall be able to communicate directly. 
The two-way nature of the conference bridge will ensure that they are already connected to all appropriate downlink 
channels. 

UPLINK_RELEASE: When the service subscriber who has access to the uplink wants to release the channel, then a 
message indicating release of the uplink is required to be sent from the MS to the BSS on the FACCH. 

NOTE 17: For different cases of uplink release and the related message flows refer to Figure 6b to 6g. 

UPLINK_RELEASE_INDICATION: The BSS informs the MSC of the upHnk release. 

FORWARD_GROUP CALL_SIGNALLING (uplink release indication): The anchor MSC indicates to all relay 
MSCs that the uplink is free. On receipt of the uplink free indication the relay MSC shall send an UPLINK RELEASE 
message to every BSS of the group call area to indicate that the uplink free. 
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NOTE: The figure describes the handling, if the IVISC decides to have a subsequent talker on a dedicated channel. 
Figure 4b: Signalling information required for the voice group call uplink access in the anchor MSC 
with talker priority "emergency subscriber" and pre-emption of the current talker (normal case, 
subsequent talker on dedicated channel, without contention resolution) 

UPLINK_ACCESS: This is sent on the uplink of the voice group call channel using random access procedures. The 
UPLINK_ACCESS message is similar to a channel request but sent on the group call channel uplink. The establishment 
cause for an emergency subscriber request as defined in 3GPP TS 44.018 shall be used for this purpose. The mobile 
station may send repeated UPLINK_ACCESS messages (see 3GPP TS 44.018). 

VGCS_UPLINK_GRANT: The reply to the uplink request sent on the voice group channel downlink containing 
information for synchronisation of the mobile station to the network and uplink access contention resolution. The 
VGCS_UPLINK_GRANT message shall therefore include a request reference (reflecting the UPLINK_ACCESS) and 
the physical information required for transmission on the voice group call channel uplink. On receipt of a 
VGCS_UPLINK_GRANT, the related mobile station can start to send speech directly. 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the uplink is now busy. UPLINK_BUSY indicates the talker priority "emergency subscriber" of the new talking service 
subscriber to all listening service subscribers. 

NOTE 18: The order of UPLINK_BUS Y and SABM message is independent. 
SABM(L3msg): The layer 2 link is set up and layer 3 information on classmark and mobile station identity included. 
UA(L3msg): The layer 2 link is acknowledged and the layer 3 information reflected for contention resolution. 

NOTE 19: Dedicated signalling connection on the main DCCH needs to be established. 

UPLINK_REQUEST: The request for the uplink containing the MS identity and the talker priority is indicated to the 
MSC. Only one request per BSS shall be forwarded. 

NOTE 20: As the BSS supports the use of talker priorities and receives from the MS a talker priority different from 
"normal subscriber", the BSS delays the sending of the UPLINK_REQUEST message to the MSC, until 
SABM(L3msg) with the MS identity is received from the MS. Then the BSS includes the layer 3 
message, the talker priority, and the cell identity of the cell where the UPLINK_ACCESS message was 
received in the UPLINK_REQUEST message. In this case the UPLINK_REQUEST_CONFIRM 
message may be omitted by the BSS. 

NOTE 20a: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done by 
means of the MAP service SEND_GROUP_CALL_INFO. 

UPLINK_REQUEST_ACKNOWLEDGE: The anchor MSC acknowledges the uplink to one BSC, including the 
talker priority and the emergency mode indication. If uplink requests have been made by more than one BSC or MSC- 
R, all remaining uplink requests shall be rejected by an UPLINK_REJECT_CMD with an emergency mode indication 
(not presented in figure 4b). On reception of an UPLINK_REJECT_CMD the BSS shall send an UPLINK_REL to the 
related mobile station, followed by an UPLINK_BUSY to indicate to the mobile stations that the uplink is in use. The 
MSC shall send to other BSCs which did not send an uplink request an UPLINK_SEIZED_CMD message with an 
emergency mode indication (not presented in figure 4b). On reception of an UPLINK_SEIZED_CMD the BSS shall 
send an UPLINK_BUSY to indicate to the mobile stations that the uplink is in use. 

The anchor MSC may also include additional information about the new talking service subscriber in the 
UPLINK_REQUEST_ACKNOWLEDGE, UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages, if the 
information is available when sending these messages. The BSS may include the additional information in the 
UPLINK_BUS Y messages, if the information is available when sending these messages and there is sufficient space 
available in the messages. 
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UPLINK_BUSY: This connectionless RR message is sent on the downUnk FACCH to inform all mobile stations that 
the uplink is now busy with talker priority "emergency subscriber" and that the emergency mode is set in the network. 
The message is repeated on the FACCH every Tl seconds. 

FORWARD_GROUP CALL_SIGNALLING (uplink seized command, emergency subscriber, add info): This 
message is sent to all relay MSCs, to inform all mobile stations roaming in parts of the group call area which are 
controlled by relay MSCs, that the uplink is now busy for a talker with talker priority "emergency subscriber" and that 
the emergency mode indication shall be signalled. Furthermore, the message provides additional information about the 
new talking service subscriber, if available. 

ASS_REQ: This message contains details of the resource(s) required for the dedicated connection. 

ASSIGNMENT_CMD: This message contains details of the resource(s) required and triggers the assignment 
procedure of the dedicated channel at the MS. 

ASSIGNMENT_COMP: Standard message. 

ASS_COMP: Standard message. 

VGCS_ADD_INFO: The MSC sends additional information about the new talking service subscriber to all BSCs, 
unless the information was already included in the UPLINK_REQUEST_ACKNOWLEDGE, 
UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages. The BSCs broadcast ADDJNFO messages 
containing the additional information to all listeners (not shown in figure 4b) , unless the information was already 
included in the UPLINK_BUSY messages. Additionally, the MSC sends the additional information on the dedicated 
connection for the previous talker, before this connection is released. 

CLEAR COMMAND: The MSC requests the BSS to clear radio and terrestrial resources associated with previous 
talker. 

CLEAR_COMP: Standard message. 

CHAN_RELEASE: The BSS sends a channel release message to the previous talker's mobile station including the 
channel description of the voice group call channel to which the mobile station shall tune to. Additionally the BSS 
includes the talker priority of the new talker and the additional information, if available, and the emergency mode 
indication, if applicable. 

DISC: Two layer 2 disconnect messages shall be sent by the mobile station to the network. 

SCCP_RLSD: Standard message. 

SCCP_RLC: Standard message. 

Conversation proceeds: Once the mobile station has control of the uplink, it shall be able to communicate directly. 
The two-way nature of the conference bridge will ensure that they are already connected to all appropriate downlink 
channels. 
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Figure 4c: Signalling information required for the voice group call uplink access 
in the anchor MSC with "emergency mode reset request" 

UPLINK_ACCESS: This is sent on the uplink of the voice group call channel using random access procedures. The 
UPLINK_ACCESS message is similar to a channel request but sent on the group call channel uplink. The establishment 
cause for emergency mode reset request as defined in 3GPP TS 44.018 shall be used for this purpose. 

EMERGENCY_RESET_IND: The reception of an emergency mode reset request is indicated to the MSC. Only one 
request per BSC shall be forwarded. 

NOTE 21: The BSS delays the sending of the EMERGENCY_RESET_IND message to the MSC, until 

SABM(L3msg) with the MS identity is received from the MS. Then the BSS includes the layer 3 message 
and the cell identity of the cell where the UPLINK_ ACCESS message was received in the 
EMERGENCY_RESET_IND message. 

NOTE 21a: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done by 
means of the MAP service SEND_GROUP_CALL_INFO. 

VGCS_UPLINK_GRANT: The reply to the uplink request sent on the voice group channel downlink containing 
information for synchronisation of the mobile station to the network and uplink access contention resolution. The 
VGCS_UPLINK_GRANT message shall therefore include a request reference (reflecting the UPLINK_ACCESS) and 
the physical information required for transmission on the voice group call channel uplink. 
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SABM(L3msg): The layer 2 link is set up and layer 3 information on classmark and mobile station identity included. 

UA(L3msg): The layer 2 link is acknowledged and the layer 3 information reflected for contention resolution. 

UPLINK_RELEASE: When the BSS has forwarded the emergency mode reset request it releases the layer 2 link. A 
message indicating release of the uplink is required to be sent from the BSS to the MS on the FACCH. 

EMERGENCY_RESET_COMMAND: The anchor MSC commands all BSCs involved in the voice group call to 
reset the emergency mode. If the BSC receives an EMERGENCY_RESET_COMMAND message, it changes the 
content of the NCH to indicate "no emergency mode" and the talker priority of the current talking service subscriber to 
"normal subscriber", if the previous uplink status was uplink busy with talker priority "emergency subscriber". 

FORWARD_GROUP CALL_SIGNALLING (emergency mode reset command): This message is sent to all relay 
MSCs, to inform all BSCs controlled by relay MSCs that the emergency mode indication shall not be sent any longer 
and that the talker priority of the current talking service subscriber is changed to "normal subscriber", if the previous 
uplink status was uplink busy with talker priority "emergency subscriber". 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the voice group call is no longer in emergency mode and that the talker priority was changed to "normal subscriber", if 
the previous uplink status was uplink busy with talker priority "emergency subscriber". The message is repeated on the 
FACCH every Tl seconds. 

Conversation proceeds: The conversation of the current talker is not interrupted. 
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Figure 4d: Signalling information required for the voice group call uplink request via RACH with 
talker priority "privileged subscriber" in the anchor MSC and pre-emption of the current talker 

(normal case, without contention resolution) 

RACH(CHAN_REQ): Standard message to request an SDCCH. 

IMM_ASS: Standard message sent on the AGCH. 

SABM (PRIORITY_UPLINK_REQ): L3 message PRIORITY_UPLINK_REQ sent on the allocated channel. 

UA (PRIORITY_UPLINK_REQ): This message is used to acknowledge the layer 2 link and provide contention 
resolution of the priority uplink request. 

UPLINK_BUSY (not presented in figure 4d): If validation of Priority Uplink Requests applies for the group call, the 
BSS, on receipt of a valid Priority Uplink Request, shall send an UPLINK_BUSY on the downlink FACCH to inform 
all mobile stations that a priority request has been made and to provide a new token. The message is sent on Tbb expiry. 

CHAN_RELEASE: The BSS sends a channel release message to the service subscriber's mobile station. 

DISC: Standard message to release the layer 2 link. 

UA: Standard message to acknowledge release of the layer 2 link. 

UPLINK_REQUEST: The request for the uplink containing the MS identity and the talker priority is indicated to the 
MSC. Only one request per BSS shall be forwarded. 

UPLINK_REQUEST_ACKNOWLEDGE (privileged subscriber): The anchor MSC acknowledges the upHnk to 
one BSC. If uplink requests have been made by more than one BSC or MSC-R, all remaining uplink requests shall be 
rejected by an UPLINK_REJECT_CMD which is not presented in figure 4d. On reception of an 
UPLINK_REJECT_CMD the BSS shall send an UPLINK_REL to the related mobile station, followed by an 
UPLINK_BUSY to indicate to the mobile stations that the uplink is in use. The MSC shall send to other BSCs which 
did not send an uplink request an UPLINK_SEIZED_CMD message which is not presented in figure 4d. On reception 
of an UPLINK_SEIZED_CMD the BSS shall send an UPLINK_BUSY to indicate to the mobile stations that the uplink 
is in use. 

The anchor MSC may also include additional information about the new talking service subscriber in the 
UPLINK_REQUEST_ACKNOWLEDGE, UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages, if the 
information is available when sending these messages. The BSS may include the additional information in the 
UPLINK_BUS Y messages, if the information is available when sending these messages and there is sufficient space 
available in the messages. 

UPLINK_RELEASE: Upon receipt of an UPLINK_REQUEST_ACKNOWLEDGE, UPLINK_REJ or 
UPLINK_SEIZED_CMD indicating the talker priority of the new talker, the BSC releases the current talker from the 
uplink by sending a message requesting release of the uplink to the mobile station on the FACCH. 

DISC: Standard message to release the layer 2 link. 

UA: Standard message to acknowledge release of the layer 2 link. 

NOTE 21b: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done by 
means of the MAP service SEND_GROUP_CALL_INFO. 

FORWARD_GROUP CALL_SIGNALLING (uplink seized command, privileged subscriber, add info): This 
message is sent to all relay MSCs, to inform all mobile stations roaming in parts of the group call area which are 
controlled by relay MSCs, that the uplink is now busy for a talker with talker priority "privileged subscriber". 
Furthermore, the message provides additional information about the new talking service subscriber, if available. 
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VGCS_UPLINK_GRANT: The reply to the priority upHnk request sent on the voice group channel downlink 
containing information for synchronisation of the mobile station to the network and uplink access contention resolution. 
The VGCS_UPLINK_GRANT message shall therefore include a request reference (reflecting the 
PRIORITY_UPLINK_REQUEST) and the physical information required for transmission on the voice group call 
channel uplink. On receipt of a VGCS_UPLINK_GRANT, the related mobile station can start to send speech directly. 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the uplink is now busy. If the network supports talker priorities, then the UPLINK_BUS Y indicates the talker priority of 
the current talking service subscriber to all listening service subscribers and additionally, if the emergency mode is set 
in the network, the emergency mode indication. The message is repeated on the FACCH every Tl seconds. If validation 
of Priority Uplink Requests applies each periodic UPLINK_BUSY message shall include a new token (i.e. a new token 
is broadcast every Tl seconds). 

NOTE: The order of UPLINK_BUS Y and S ABM message is independent. 

SABM(L3msg): The layer 2 link is set up and layer 3 information on classmark and mobile station identity included. 

UA(L3msg): The layer 2 link is acknowledged and the layer 3 information reflected for contention resolution. 

UPLINK_REQUEST_CONFIRM: The BSS confirms the upHnk use to the MSC together with the mobile station 
identity, classmark information and optionally the CKSN. 

VGCS_ ADD_ INFO: The MSC sends additional information about the new talking service subscriber to all BSCs, 
unless the information was already included in the UPLINK_REQUEST_ACKNOWLEDGE, 
UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages. The BSCs broadcast ADDJNFO messages 
containing the additional information to all listeners (not shown in figure 4d) , unless the information was already 
included in the UPLINK_BUSY messages. 

Conversation proceeds: Once the mobile station has control of the uplink, it shall be able to communicate directly. 
The two-way nature of the conference bridge will ensure that they are already connected to all appropriate downlink 
channels. 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 



82 



ETSI TS 143 068 V9.2.0 (2010-10) 



MS BSS MSC-A 

n 

Conversation proceeds with talker priority 

"emergency subscriber" 

< > 



MS leaves the group call 
RACH(CHAN_REQ) 



MSC-R 



IMM_ASS 



SABM(Priority Uplink 
Request) 
> 



UA(Priority Uplink Req) 
< 

CHAN_RELEASE 



DISC 



UA 



MS rejoins the group call 



UPLINK_BUSY 
< 



EMERGENCY.RESET 
_IND 
> 



EMERGENCY_RESET 
.COMMAND 



Conversation proceeds with talker priority 

"normal subscriber" 

< > 

U 



MSC-A checks 
subscription for group ID 
and talker priority 
(NOTE 21c) 



FORW. GROUP CALL 
SIGNAL (emergency 
mode reset command) 



Figure 4e: Signalling information required for the voice group call uplink request via RACH with 
"emergency mode reset request" in the anchor MSC (normal case, without contention resolution) 

RACH(CHAN_REQ): Standard message to request an SDCCH. 

IMM_ASS: Standard message sent on the AGCH. 

SABM (PRIORITY_UPLINK_REQ): L3 message PRIORITY_UPLINK_REQ sent on the allocated channel. 

UA (PRIORITY_UPLINK_REQ): This message is used to acknowledge the layer 2 link and provide contention 
resolution of the priority uplink request. 

CHAN_RELEASE: The BSS sends a channel release message to the service subscriber's mobile station. 

DISC: Standard message to release the layer 2 link. 
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UA: Standard message to acknowledge release of the layer 2 link. 

UPLINK_BUSY (not presented in figure 4e): If validation of Priority Uplink Requests applies for the group call, the 
BSS, on receipt of a valid Priority Uplink Request, shall send an UPLINK_BUSY on the downlink FACCH to inform 
all mobile stations that a priority request has been made and to provide a new token. The message is sent on Tbb expiry. 

EMERGENCY_RESET_IND: The reception of an emergency mode reset request is indicated to the MSC. Only one 
request per BSS shall be forwarded. 

EMERGENCY_RESET_COMMAND: The anchor MSC commands all BSCs involved in the voice group call to 
reset the emergency mode. If the BSC receives an EMERGENCY_RESET_COMMAND message, it changes the 
content of the NCH to indicate "no emergency mode" and the talker priority of the current talking service subscriber to 
"normal subscriber", if the previous uplink status was uplink busy with talker priority "emergency subscriber". 

NOTE 21c: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done by 
means of the MAP service SEND_GROUP_CALL_INFO. 

FORWARD_GROUP CALL_SIGNALLING (emergency mode reset command): This message is sent to all relay 
MSCs, to inform all BSCs controlled by relay MSCs that the emergency mode indication shall not be sent any longer 
and that the talker priority of the current talking service subscriber is changed to "normal subscriber", if the previous 
uplink status was uplink busy with talker priority "emergency subscriber". 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the voice group call is no longer in emergency mode and that the talker priority was changed to "normal subscriber", if 
the previous uplink status was uplink busy with talker priority "emergency subscriber". The message is repeated on the 
FACCH every Tl seconds. . If validation of Priority Uplink Requests applies each periodic UPLINK_BUSY message 
shall include a new token (i.e. a new token is broadcast every Tl seconds). 

Conversation proceeds: The conversation of the current talker is not interrupted. 
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Figure 5: Signalling information required for the voice group call uplink access 
in the relay MSC without talker priority (normal case, without contention resolution) 

UPLINK_FREE: This connectionless RR message is repeatedly sent by the BSS on the main signalling link (FACCH) 
to inform all mobile stations of the voice group call members that the uplink is free. 

UPLINK_ACCESS: This is sent on the uplink of the voice group call channel using random access procedures. The 
UPLINK_ ACCESS message is similar to a channel request but sent on the group call channel uplink. The establishment 
cause for subsequent talker uplink request as defined in 3GPP TS 44.018 shall be used for this purpose. The mobile 
station may send repeated UPLINK_ACCESS messages (see 3GPP TS 44.018). 

UPLINK_REQUEST: The request for the upHnk is indicated to the MSC. Only one request per BSC shall be 
forwarded. 
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NOTE 22: If the BSS supports the use of talker priorities and receives from the MS a talker priority different from 
"normal subscriber", the BSS delays the sending of the UPLINK_REQUEST message to the MSC, until 
SABM(L3msg) is received from the MS. Then the BSS includes the layer 3 message, the talker priority, 
and the cell identity of the cell where the UPLINK_ACCESS message was received in the 
UPLINK_REQUEST message. In this case the UPLINK_REQUEST_CONFIRM message may be 
omitted by the BSS. 

VGCS_UPLINK_GRANT: The reply to the uplink request sent on the voice group channel downlink containing 
information for synchronisation of the mobile station to the network and uplink access contention resolution. The 
VGCS_UPLINK_GRANT message shall therefore include a request reference (reflecting the UPLINK_ACCESS) and 
the physical information required for transmission on the voice group call channel uplink. On receipt of a 
VGCS_UPLINK_GRANT, the related mobile station can start to send speech directly. 

NOTE 23:UPLINK_FREE messages are stopped inmiediately. 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the uplink is now busy. 

NOTE 24: If the BSS supports the use of talker priorities, then it indicates the talker priority of the current talking 

service subscriber and the status of the emergency mode in the UPLINK_BUS Y message and repeats the 
message on the FACCH every Tl seconds. 

NOTE 25: The order of UPLINK_BUS Y and SABM message is independent. 

SABM (L3msg): The layer 2 link is set up and layer 3 information on classmark and mobile station identity included. 

UA (L3msg): The layer 2 link is acknowledged and the layer 3 information reflected for contention resolution. 

PROCESS_GROUP CALL_SIGNALLING (uplink request): This message is sent to the anchor MSC, to indicate 
that the uplink is requested by a subscriber roaming in the relay MSC area. 

NOTE 26: If the UPLINK_REQUEST message contained the layer 3 message, the message provides additional 
information about the new talking service subscriber, if available. 

FORWARD_GROUP CALL_SIGNALLING (uplink request ack): This message is sent to the relay MSC, to 
indicate that the uplink is granted to the mobile station roaming in parts of the group call area which are controlled by 
relay MSC. 

UPLINK_REQUEST_ACKNOWLEDGE: The relay MSC acknowledges the uplink to one BSC. If uplink requests 
have been made by more than one BSC, all remaining uplink requests shall be rejected by an UPLINK_REJECT_CMD 
which is not presented in figure 5. On reception of an UPLINK_REJECT_CMD the BSS shall send an UPLINK_REL 
to the related mobile station, followed by an UPLINK_BUSY to indicate to the mobile stations that the uplink is in use. 
The MSC shall send to other BSCs which did not send an uplink request an UPLINK_SEIZED_CMD message which is 
not presented in figure 5. On reception of an UPLINK_SEIZED_CMD the BSS shall send an UPLINK_BUSY to 
indicate to the mobile stations that the uplink is in use. If the BSS supports the use of talker priorities, then it indicates 
the talker priority of the current talking service subscriber and the status of the emergency mode in the UPLINK_BUS Y 
message and repeats the message on the FACCH every Tl seconds. 

UPLINK_REQUEST_CONFIRM : The BSS confirms the uplink use to the MSC together with the mobile station 
identity. 

NOTE 26a: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done by 
means of the MAP service SEND_GROUP_CALL_INFO. 

VGCS_ADD_INFO: The MSC sends additional information about the new talking service subscriber to all BSCs. The 
BSCs broadcast ADD_INFO messages containing the additional information to all listeners (not shown in figure 5). 

PROCESS_GROUP CALL_SIGNALLING (additional info): This message is sent to the anchor MSC to provide 
information about the new talking service subscriber. The anchor MSC forwards the message to all other relay MSCs. 

NOTE 27: This message is omitted, if the additional info was already included in the PROCESS_GROUP 
CALL_SIGNALLING (upHnk request) message. 
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Conversation proceeds: Once the mobile station has control of the uplink, it shall be able to communicate directly. 
The two-way nature of the conference bridge will ensure that they are already connected to all appropriate downlink 
channels. 

UPLINK_RELEASE: When the service subscriber who has access to the uplink wants to release the channel, then a 
message indicating release of the uplink is required to be sent from the MS to the BSS on the FACCH. 

NOTE 28: For different cases of uplink release and the related message flows refer to Figure 6.b to 6.g. 

UPLINK_RELEASE_INDICATION: The BSS informs the MSC on the upHnk release. 

PROCESS_GROUP CALL_SIGNALLING (uplink release indication): The relay MSC indicates to the anchor 
MSC that the uplink is free. 
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Figure 5a: Signalling information required for the voice group call uplink request via RACH with 
talker priority "privileged subscriber" in the relay MSC (normal case, without contention resolution) 

RACH(CHAN_REQ): Standard message to request an SDCCH. 

IMM_ASS: Standard message sent on the AGCH. 

SABM (PRIORITY_UPLINK_REQ): L3 message PRIORITY_UPLINK_REQ sent on the allocated channel. 

UA (PRIORITY_UPLINK_REQ): This message is used to acknowledge the layer 2 link and provide contention 
resolution of the service request. 

CHAN_RELEASE: The BSS sends a channel release message to the service subscriber's mobile station. 

DISC: Standard message to release the layer 2 link. 

UA: Standard message to acknowledge release of the layer 2 link. 

UPLINK_BUSY (not presented in figure 5a): If validation of Priority Uplink Requests applies for the group call, the 
BSS, on receipt of a valid Priority Uplink Request, shall send an UPLINK_BUSY on the downlink FACCH to inform 
all mobile stations that a priority request has been made and to provide a new token. The message is sent on Tbb expiry. 

UPLINK_REQUEST: The request for the upHnk is indicated to the MSC. Only one request per BSS shall be 
forwarded. 

NOTE 28a: In a RANflex configuration the uplink requesting subscriber's VMSC may be different from his current 
location area's group call serving MSC. In this case the retrieval of info from the (distant) VLR is done by 
means of the MAP service SEND_GROUP_CALL_INFO. 

PROCESS_GROUP_CALL_SIGNALLING (uplink request, privileged subscriber, add info): This message is 
sent to the anchor MSC, to indicate that the uplink is requested by a subscriber with talker priority "privileged 
subscriber" roaming in the relay MSC area. Furthermore, the message provides additional information about the service 
subscriber requesting the uplink, if additional information is available. 

FORWARD_GROUP_CALL_SIGNALLING (uplink request ack): This message is sent to the relay MSC, to 
indicate that the uplink is granted to the mobile station roaming in parts of the group call area which are controlled by 
the relay MSC. 

UPLINK_REQUEST_ACKNOWLEDGE: The relay MSC acknowledges the uplink to one BSC. If uplink requests 
have been made by more than one BSC, all remaining uplink requests shall be rejected by an UPLINK_REJECT_CMD 
which is not presented in figure 5a. On reception of an UPLINK_REJECT_CMD the BSS shall send an UPLINK_REL 
to the related mobile station, followed by an UPLINK_BUSY to indicate to the mobile stations that the uplink is in use. 
The MSC shall send to other BSCs which did not send an uplink request an UPLINK_SEIZED_CMD message which is 
not presented in figure 5a. On reception of an UPLINK_SEIZED_CMD the BSS shall send an UPLINK_BUSY to 
indicate to the mobile stations that the uplink is in use. 

The anchor MSC may also include additional information about the new talking service subscriber in the 
UPLINK_REQUEST_ACKNOWLEDGE, UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages, if the 
information is available when sending these messages. 

UPLINK_RELEASE: Upon receipt of an UPLINK_REQUEST_ACKNOWLEDGE, UPLINK_REJECT_CMD or 
UPLINK_SEIZED_CMD indicating the talker priority of the new talker, the BSC releases the current talker from the 
uplink by sending a message requesting release of the uplink to the mobile station on the FACCH. 
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DISC: Standard message to release the layer 2 link. 

UA: Standard message to acknowledge release of the layer 2 link. 

VGCS_UPLINK_GRANT: The reply to the priority uplink request sent on the voice group channel downlink 
containing information for synchronisation of the mobile station to the network and uplink access contention resolution. 
The VGCS_UPLINK_GRANT message shall therefore include a request reference (reflecting the 
PRIORITY_UPLINK_REQUEST) and the physical information required for transmission on the voice group call 
channel uplink. On receipt of a VGCS_UPLINK_GRANT, the related mobile station can start to send speech directly. 

UPLINK_BUSY: This connectionless RR message is sent on the downlink FACCH to inform all mobile stations that 
the uplink is now busy. If the network supports talker priorities, then the UPLINK_BUS Y indicates the talker priority of 
the current talking service subscriber to all listening service subscribers and additionally, if the emergency mode is set 
in the network, the emergency mode indication. The message is repeated on the FACCH every Tl seconds. If validation 
of Priority Uplink Requests applies each periodic UPLINK_BUSY message shall include a new token (i.e. a new token 
is broadcast every Tl seconds). The ESS may include the additional information about the new talking service 
subscriber in the UPLINK_BUS Y message, if the information is available when sending this message and there is 
sufficient space available in the message. 

NOTE: The order of UPLINK_BUS Y and S ABM message is independent. 

SABM (L3msg): The layer 2 link is set up and layer 3 information on classmark and mobile station identity included. 

UA (L3msg): The layer 2 link is acknowledged and the layer 3 information reflected for contention resolution. 

UPLINK_REQUEST_CONFIRM: The BSS confirms the upHnk use to the MSC together with the mobile station 
identity, classmark information and optionally the CKSN. 

VGCS_ ADD_ INFO: The MSC sends additional information about the new talking service subscriber to all BSCs, 
unless the information was already included in the UPLINK_REQUEST_ACKNOWLEDGE, 
UPLINK_REJECT_CMD and UPLINK_SEIZED_CMD messages. The BSCs broadcast ADDJNFO messages 
containing the additional information to all listeners (not shown in figure 5a) , unless the information was already 
included in the UPLINK_BUSY messages. 

Conversation proceeds: Once the mobile station has control of the uplink, it shall be able to communicate directly. 
The two-way nature of the conference bridge will ensure that they are already connected to all appropriate downlink 
channels. 
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Figure 5b: Signalling information required when the talker is attached to the Anchor MSC and a 

dispatcher sends DTMF signals 

Conversation proceeds: The talker is in control of the uplink (see figure 4) and is attached to the Anchor MSC. The 
mobile station's downlink is muted to prevent any distracting echo being heard by the mobile station user. 
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DTMF Tones (start_talking) or DTMF message (start_talking): This signalling indicates the dispatcher's unmute 
request to the MSC. DTMF Tones are used by a fixed line dispatcher while the DTMF message is used by a mobile 
dispatcher. 

Grant Tone: The Anchor MSC may optionally play an in-band tone to the dispatcher to indicate that the dispatcher's 
request is recognized and that the downlink of the talking service subscriber will be unmuted The attributes of the grant 
tone (e.g. frequency and duration) are network operator specific. 

Set Parameter (D-ATT = TRUE): The Anchor MSC sends this message to the mobile station to unmute the downlink 
so that the user can hear what the dispatcher says. 

NOTE 29: This message is sent only when the downlink of the talker is muted. 

DTMF Tones (end_talking) or DTMF message (end_talking): This signalHng indicates the dispatcher's mute request 
to the MSC. DTMF Tones are used by a fixed line dispatcher while the DTMF message is used by a mobile dispatcher. 

Set Parameter (D-ATT = FALSE): Once the dispatcher indicates that he has finished speaking, the Anchor MSC 
mutes the talker's downlink. 

NOTE 30: This message is only sent when all dispatchers who have sent the unmuting request have finished their 
talk. 
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Figure 5c: Signalling information required when the talker is attached to a Relay MSC and a 

dispatcher sends DTMF signals 

Conversation proceeds: The talker is in control of the uplink (see figure 4) and is attached to a Relay MSC. The 
mobile station's downlink is muted to prevent any distracting echo being heard by the mobile station user. 

DTMF Tones (start_talking or DTMF message (start_talking): This signalling indicates the dispatcher's unmute 
request to the MSC. DTMF Tones are used by a fixed line dispatcher while the DTMF message is used by a mobile 
dispatcher. 

Grant Tone: The Anchor MSC may optionally play an in-band tone to the dispatcher to indicate that the dispatcher's 
request is recognized and that the downlink of the talking service subscriber will be unmuted. The attributes of the grant 
tone (e.g. frequency and duration) are network operator specific. 

FORWARD_GROUP_CALL_SIGNAL: This message is sent to the Relay MSC when anchor MSC wants to change 
the mute/unmute status of the talking service subscriber. In this case stateAttributes::DA = TRUE, is set. 

Set Parameter (D-ATT = TRUE/FALSE): The Relay MSC sends this message to the talker when a FORWARD 
GROUP CALL SIGNAL containing a STATE_ATTRIBUTES information element is received. The D-ATT field is set 
as received in STATE_ATTRIBUTES element. 

DTMF Tones (end_talking) or DTMF message (end_talking): This signalling indicates the dispatcher's mute request 
to the MSC. DTMF Tones are used by a fixed line dispatcher while the DTMF message is used by a mobile dispatcher. 
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FORWARD_GROUP_CALL_SIGNAL: This message is sent to the Relay MSC when the anchor MSC wants to 
change the mute/unmute status of the talking service subscriber. In this case stateAttributes::DA = FALSE is set. 

Set Parameter (D-ATT = FALSE): Once the dispatcher indicates that he has finished speaking, the MSC mutes the 
talker' s downlink again. 
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Figure 5d: Signalling information required when the talker is attached to the Anchor MSC and a 
mobile dispatcher who is roaming in a non-Anchor MSC area sends DTMF signals 

Conversation proceeds: The talker is in control of the uplink (see figure 4) and is attached to the Anchor MSC. The 
mobile station's downlink is muted to prevent any distracting echo being heard by the mobile station user. 

DTMF message (start_talking): This signalling indicates the mobile dispatcher's unmute request to visited MSC. On 
reception of the DTMF message, the visited MSC will convert it into DTMF tones and send these DTMF tones through 
the network to the anchor MSC. 

Grant Tone: The Anchor MSC may optionally play an in-band tone to the dispatcher to indicate that the dispatcher's 
request is interpreted as a request to talk and that the downlink of the talking service subscriber will be unmuted. The 
attributes of the grant tone (e.g. frequency and duration) are network operator specific. 

Set Parameter (D-ATT = TRUE): The Anchor MSC sends this message to the talker to force his mobile station to 
unmute its downlink so that the user can hear what the dispatcher says. 

DTMF message (end_talking): This signalling indicates the mobile dispatcher's mute request to the MSC. 

Set Parameter (D-ATT = FALSE): Once the dispatcher indicates that he has finished speaking, the Anchor MSC 
mutes the talker's downlink. 
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Figure 6: Signalling information required for the voice group call uplink release 

requested by the network 

UPLINK_REL_CMD: When the network wants to release the upHnk for any reason, except when a service subscriber 
with a higher priority has seized the upHnk, then a message requesting release of the uplink is required to be sent from 
the network to the mobile station on the FACCH. 



MS 



BSS 



MSC 



n 



Conversation proceeds with talker priority 
"normal subscriber" 



-> 



UPLINK_SEIZED CMD (privileged subscriber) 

<- 

UPLINK_RELEASE 
< 

UPLINK_BUSY 

(privileged subscriber) 



Figure 6a: Signalling information required for the voice group call uplink release 
requested by the network; preemption of the current talker by a privileged service subscriber 

UPLINK_SEIZED_CMD: When the network wants to release the uplink because a service subscriber with a higher 
priority has seized the uplink in another BSS area, an UPLINK_SEIZED_CMD indicating the talker priority of the new 
talking service subscriber is sent by the MSC. If the BSS has sent an UPLINK_REQUEST to the MSC, the MSC will 
either send UPLINK_REQUEST_ACKNOWLEDGE or UPLINK_REJECT instead of the UPLINK_SEIZED_CMD. 

The following figures 6.b to 6.g show the message flows applicable for the uplink release in normal and error cases, 
dependent on whether the talker is 

- on a dedicated link (e.g. the talker is the originator); or 

- on the group call channel (e.g. the talker is a subsequent talker). 
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NOTE: The messages CLEAR GMD, CLEAR COM, etc., are used to release the dedicated connection of the 
talker. 

Figure B.b: Uplink release for the talker on a dedicated link: normal case 
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NOTE: The messages CLEAR CMD, CLEAR COM, etc., are used to release the dedicated connection of the 
talker. The same message flow applies for all cause values different from "call control". 

Figure 6.c: Uplink release for the talker on a dedicated link: loss of radio contact or equipment failure 

(TRX, PCM ...) 
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Figure B.d: Uplink release for the talker on group call channel: normal case 
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Figure B.e: Uplink release for the talker on group call channel: loss of radio contact 
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NOTE: The messages CLEAR CIVID, CLEAR COIVI, etc., are used to release the radio and terrestrial resources for 
the cell serving the talker. The same message flow applies for all cause values different from "call control", 
and "radio interface failure". 

Figure B.f : Uplink release for the talker on group call channel after equipment failure (TRX, PCM ...), 
group call re-establishment by the BSS not supported 

The BSC shall send the message UPLINK RELEASE INDICATION with cause value "equipment failure" or another 
appropriate cause value, if a failure concerning the cell that is serving the talker was detected and the radio and 
terrestrial resources related to this cell shall be released (see figure 6.5). After receipt of the UPLINK RELEASE 
INDICATION message the MSC shall send a CLEAR COMMAND message for the respective cell. The BSC does not 
send CLEAR REQUEST in addition to UPLINK RELEASE INDICATION in order to avoid conflicts. 
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NOTE: The messages CLEAR GMD, CLEAR COM, etc., are used to release the radio and terrestrial resources for 
the cell not serving the talker. The same message flow applies also for all other cause values. 

Figure 6.g: Release after equipment failure (TRX, PCM ...) concerning a cell that is not serving the 
talker, group call re-establishment by the BSS not supported 
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The BSC shall send the message CLEAR REQUEST with cause value "equipment failure" or another appropriate cause 
value, if a failure concerning a cell not serving the talker was detected and the resources related to this cell shall be 
released (see figure 6.g). After receipt of the CLEAR REQUEST message the MSC shall send a CLEAR COMMAND 
message for the respective cell. 
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NOTE: The terrestrial resource for the group call channel is not released. 

Figure 6.h: A-interface link sharing used or group call re-establishment by the BSS supported: 
Uplink release for the talker on group call channel after equipment failure (TRX, PCM ...) 

If A-interface link sharing is used or group call re-establishment by the BSS is supported, the BSC shall send the 
message UPLINK RELEASE INDICATION with cause value "equipment failure" or another appropriate cause value, 
if a failure concerning the cell that is serving the talker was detected. In addition the BSC shall send the VGCS 
ASSIGNMENT STATUS message indicating that the connection to this cell is no longer established (see figure 6.h). If 
A-interface link sharing is used, the VGCS ASSIGNMENT STATUS message shall be sent on expiry of timer Tast. 
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NOTE: The terrestrial resource for the group call channel is not released. 

Figure 6.i: A-interface link sharing used or group call re-establishment by the BSS supported: 
Release after equipment failure (TRX, PCM ...) concerning a cell that is not serving the talker 

If A-interface link sharing is used or group call re-establishment by the BSS is supported, and a failure concerning a cell 
that is not serving the talker was detected, the BSS shall send the VGCS ASSIGNMENT STATUS message indicating 
that the connection to this cell is no longer established (see figure 6.i). If A-interface link sharing is used, the VGCS 
ASSIGNMENT STATUS message shall be sent on expiry of timer Tast. 
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Figure B.j: A-interface link sharing used or group call re-establishment by the BSS supported: 
Release after equipment failure concerning the link between MSC and BSS 

If A-interface link sharing is used or group call re-establishment by the BSS is supported, the BSC shall send the 
message CLEAR REQUEST with cause value "equipment failure" or another appropriate cause value, if a failure 
concerning the link between MSC and BSS was detected and the resources related to this connection shall be released 
(see figure 6.h). After receipt of the CLEAR REQUEST message the MSC shall send a CLEAR COMMAND message 
for the respective connection and try to establish a new connection. 
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SEND_GROUP CALL_END_SIGNAL_ACK 



Figure 7: Signalling required to disconnect the group call 

TERMINATION REQUEST: An authorized mobile station can send a TERMINATION REQUEST message to clear 
down the entire voice group call. To do this, the mobile station must have access to the uplink. The network has to 
check the IMSI to verify the calling service subscriber. If the IMSI of the mobile station which has uplink access is 
presently not known to the network, the network shall send an identity request to the mobile station 

NOTE 3 1 : Alternatively an authorized dispatcher can terminate the voice group call in which case a release message 
is received from the external network. 

NOTE 32: Alternatively an authorized mobile dispatcher can terminate the voice group call by using a specific 

DTMF message sequence. If the mobile dispatcher is controlled by the anchor MSC, the specific DTMF 
message sequence is received by the anchor MSC (see figure 7b). 
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NOTE 33: If the mobile dispatcher is controlled by a relay MSC, the specific DTMF message sequence is received 
by the relay MSC. The relay MSC converts the DTMF messages into DTMF tones and sends them 
towards the anchor MSC (see figure 7c). 

NOTE 34: Alternatively an authorized fixed line dispatcher can terminate the voice group call by using a specific 
DTMF tone sequence. In this case, the specific DTMF tone sequence is received by the anchor MSC 
(see figure Id). 

NOTE 35: Alternatively an authorized mobile station currently served by a relay MSC can clear down the entire 
group call in which case either a Release (normal call clearing) is received from the relay MSC (for the 
case when the calling service subscriber still has the initial dedicated connection to MSC-A) or a 
PROCESS_GROUP CALL_SIGNALLING message indicating call release is received from the relay 
MSC (when the calling service subscriber is on the group call channel or has a dedicated connection to 
the relay MSC). 

CLEAR CMD: This message is sent from the MSC to the BSS via each Resource Controlling SCCP connection to 
clear radio and terrestrial resources. 

VGCS_TERMIN: The MSC informs the GCR that the voice group call with the related group call reference is 
terminated. 

CHANNEL RELEASE: CHANNEL RELEASE messages are sent on all downhnk FACCH to the service subscribers. 
The CHANNEL RELEASE messages shall be repeated for a predefined period in order to provide a high probability 
that the listening mobile stations receive the message. 

CHANNEL RELEASE message is sent using I frame for the talker. 

- CHANNEL RELEASE messages are sent using UI frames for listeners. 

In addition, release messages are sent to all related dispatchers and relay MSCs. If the group call termination is initiated 
by an entitled dispatcher, and there is a dedicated connection for the calling service subscriber between the anchor MSC 
and the relay MSC, the anchor MSC shall release this connection with cause 'normal call clearing'. 

SEND_GROUP CALL_END_SIGNAL_ACK: The dialogues to all relay MSCs are closed. 

CLEAR COMPLETE: standard message. 

SCCP_RLSD: standard message sent via resource controlling SCCP connection. 

SCCP_RLC: standard message. 

CLEAR CMD: This message is sent from the MSC to the BSS via the Call Controlling SCCP connection, after all the 
terrestrial resources associated with the BSS for this group call have been released. 

CLEAR COMPLETE: standard message. 

SCCP_RLSD: standard message sent via call controlling SCCP connection. 

SCCP_RLC: standard message. 
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Same as Standard case 
For each cell in the Group 
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Figure 7a: Signalling information required for establishing voice group calls 
by a service subscriber using immediate setup 

SYSJNFO (NCH allocated): Message used to indicate if the NCH is allocated on the CCCH in the cell. 
Initial RACH CHAN_REQ: Standard message. 
IMM_ASSIGNMENT: Standard message sent on the AGCH. 
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IMMEDIATE_SETUP: This message including all details of the voice group call is sent by the MS to the network in 
order to set-up a group call immediately, i.e. without previous establishment of an MM connection. 

UA (IMMEDIATE_SETUP): This message is used to acknowledge the layer 2 link and provide contention resolution 
of the immediate setup. 

NOTE 36: Authentication and/ or activation of Ciphering may be performed before or after sending a CONNECT 
message. If ciphering has not been activated before sending a CONNECT message, a CM_SERVICE 
ACCEPT may be sent before the CONNECT message by the MSC, however sending of the 
CM_SERVICE_ACCEPT is not mandatory. 
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Figure 7b: Signalling required for communication of DTMF digit entry by an entitled mobile 
dispatcher, if the mobile dispatcher is controlled by the anchor MSC of the group call. 
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Figure 7c: Signalling required for communication of DTMF digit entry by an entitled mobile 
dispatcher, if the mobile dispatcher is controlled by a visited MSC (could be a relay MSC) of the 

group call. 
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Figure 7d: Signalling required for communication of DTMF digit entry by an entitled fixed line 

dispatcher. 
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UPLINK ACESS 



VGCS UPLINK GRANT 



<___ 
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<___ 
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Figure 7e: Validation of Priority Uplink Requests for ciphered group calls 



NOTE: 

MS 
MSs 
Token (A, B... J) 



= service subscriber requesting priority access to the uplink 

= all service subscribers in the group, in this BSS area 

= 32bit random number, generated by the BSS. Broadcast in UPLINK BUSY messages on the 



ciphered group channel downlink (FACCH) 



Figure 7e Scenarios: 

L For a service subscriber originated group call, if the call is ciphered, the BSS includes a token in the first 

UPLINK BUSY message sent on the group channel downlink. For a dispatcher originated group call, if the call 
is ciphered, the BSS includes a token in the first UPLINK BUSY message sent after the first successful uplink 
access by a service subscriber. A new token is sent in each periodic UPLINK BUSY message, every Tl 
seconds. If the old token has not been used it remains valid for a further Ttv seconds along with the new token. 
Once Ttv expires only the new token is valid. (If, within Ttv seconds, a Priority Uplink Request is received 
with the old token, the request is accepted, the old and new tokens are invalidated and an UPLINK BUSY, 
with another new token and the priority of the accepted request, is sent after Tbb ms on the group channel 
downlink.) 

2. Subscriber on the group call with 'Privilege' or 'Emergency' subscription requests the uplink. Token matches 
in BSS. A new token, and the priority of the accepted request, are sent after Tbb ms in an UPLINK BUSY on 
the group channel downlink to ensure higher priority requests can still be made in the cells covered by this 
BSS. Timer Tl is reset and restarted. 

3. Subscriber on the group call with 'Emergency Mode Reset' subscription requests an 'Emergency Mode Reset'. 
Token matches in BSS. A new token is sent after Tbb ms in an UPLINK BUSY on the group channel 
downlink. Timer Tl is reset and restarted. 

4. User not on the group call makes fraudulent uplink request. Token does not match in BSS. BSS discards 
message. BSS continues to broadcast tokens in periodic UPLINK BUSY messages. 

5. Subscriber on the group call with a 'Privilege', 'Emergency' or 'Emergency Mode Reset' subscription requests 
the uplink. No token included in the request. BSS discards message. BSS continues to broadcast tokens in 
periodic UPLINK BUSY messages. 

6. Subscriber with a 'Privilege' subscription requests the uplink. Token matches in BSS. A new token, and the 
priority of the accepted request (i.e. 'Privilege'), are sent after Tbb ms in an UPLINK BUSY on the group 
channel downlink, however a subscriber with an 'Emergency' subscription requests the uplink before the new 
token has been received by the MS (use of the old token, causes the message to be discarded by BSS). On 
receipt of the UPLINK BUSY with new token and priority 'Privilege', the MS resends the Priority Uplink 
Request ('Emergency') with the new token. 

7. When a subscriber releases the uplink, timer Tl is stopped and the BSS broadcasts UPLINK FREE. A token is 
not broadcast while the uplink is free. 
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A subscriber requests the uplink by sending an UPLINK ACCESS on the group channel uplink. The BSS 
grants the uplink and a UPLINK BUSY including a new token, and the current talker priority, is sent on the 
group channel downlink. A new token and the current talker priority is also sent in UPLINK BUSY on the 
group channel downlink if the uplink becomes busy because it is granted in another BSS or MSC area and an 
UPLINK_REJECT_CMD or UPLINK_SEIZED_CMD is received by the BSS. 
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Figure 7f : A listener in the anchor MSC area sends application-specific data to the other group call 
members, while the group call channel uplink in the cell is free 

UPLINK_ACCESS (Establishment_cause=UL Request for sending application-specific data): This message is 
sent on the upHnk of the voice group call channel using random access procedures. The UPLINK ACCESS message is 
similar to a channel request but sent on the group call channel uplink. 

VGCS_UPLINK_GRANT: The BSS grants the upHnk of its group call channel immediately. The reply to the uplink 
request sent on the voice group channel downlink containing information for synchronisation of the mobile station to 
the network and uplink access contention resolution. The VGCS_UPLINK_GRANT message shall therefore include a 
request reference (reflecting the UPLINK_ACCESS) and the physical information required for transmission on the 
voice group call channel uplink. 

SABM (DATAJNDICATION (Application_data)): The MS sends a SABM message with its mobile station identity 
and the Application data to the BSS. 

UA (DATAJNDICATION (Application_data)): This message is used to acknowledge the layer 2 link and provide 
contention resolution of the data indication. 

NOTIFY_APPLICATION_DATA (Application_data): If the network option of immediate distribution of 
application-specific data by the BSS is activated, on receiving the application data sent from the MS, the BSS 
broadcasts the application data immediately to the cells within the BSC area in a notification message on the FACCH. 
Optionally, the NOTIFY_APPLICATION_DATA message for application-specific data is repeated on the group call 
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channel downlink. As a prerequisite for the immediate distribution, during the establishment phase of the voice group 
call the BSC stored the cell identities of the cells belonging to the group call area and served by the BSC. 

UPLINK_APPLICATION_DATA (CID, IDI, DATAJNDICATION): The BSS adds the sender's cell identifier 
(CID) and passes the L3 information (DATA_INDICATION) via the UPLINK_APPLICATION_DATA message to the 
MSC. If the BSC has immediately distributed the application data to its BSC area, the BSC shall additionally include 
the Immediate Distribution Indicator (IDI). 

UPLINK_RELEASE: The BSS immediately releases the uplink by sending this message to the MS on the FACCH. 

DISC: Standard message to release the layer 2 link. 

UA: Standard message to acknowledge release of the layer 2 link. The mobile station returns to group receive mode. 

FORWARD_GROUP CALL_SIGNALLING (NOTIFICATION_DATA): On receipt of the 
UPLINK_APPLICATION_DATA message, the anchor MSC shall put the application data and optionally the mobile 
subscriber's MSISDN into the BSSMAP message NOTIFICATION_DATA and distribute the message towards all relay 
MSCs. 

Editor's note: The condition for including the MSISDN in the BSSMAP message NOTIFICATION_DATA is ffs. 

NOTIFICATION_DATA: The MSC sends NOTIFICATION_DATA messages with the appHcation data to all BSSs 
in their MSC area involved in the group call. If the originating BSC has immediately distributed the application data to 
its BSC area, the MSC shall not send the NOTIFICATION DATA message to the originating BSC. 

NOTIFY_APPLICATION_DATA (Application_data): The BSS broadcasts the appHcation data to all Hsteners and 
the talker, if any, in a notification message on the FACCH. Optionally the NOTIFY_APPLICATION_DATA message 
for application-specific data is repeated on the group call channel downlink. (The broadcast of the application data by 
the other BSSs is not shown in figure 7f.) 
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Conversation with taker proceeds 



BSS 



Datajndication 
(Application_data) 



Notify_Appl_data 
(Application_data) 



Upl_Application_Data 
(CID, Datajnd ) 



Notification_Data 



Forw_GC_signalling 
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Conversation with talker proceeds 



Notification_Data 



Figure 7g: A talker in the anchor MSC area sends application-specific data to the other group call 

members. 

DATAJNDICATION (Application_data): Since the talker has the uplink and a layer 2 Hnk is estabHshed, the MS 
can send the application data to the BSS. 

For the meaning of the other messages see figure 7f. The option of immediate distribution of the application- specific 
data by the BSC can be applied also in figure 7g, although it is not shown in the message flow (for details see figure 7f). 
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Figure 7h: A listener in a relay MSC area sends application-specific data to the other group call 
members, while the group call channel uplink in the cell is free. 

In the following only the messages different from figure 7f are explained: 

PROCESS_GROUP CALL_SIGNALLING (NOTIFICATION_DATA): On receipt of the 
UPLINK_APPLICATION_DATA message the relay MSC shall put the application data and optionally the mobile 
subscriber's MSISDN into the BSSMAP message NOTIFICATION_DATA and send the message to the anchor MSC. 

Editor's note: The condition for including the MSISDN in the BSSMAP message NOTIFICATION_DATA is for 
FFS. 

FORWARD_GROUP CALL_SIGNALLING (NOTIFICATION_DATA): On receipt of the 
NOTIFICATION_DATA, the anchor MSC shall forward the message to all relay MSCs except the relay MSC from 
which the NOTIFICATION_DATA was received. The relay MSCs shall send the NOTIFICATION_DATA messages 
with the application data to all BSSs in their MSC area involved in the group call. The BSSs shall broadcast the data to 
all listeners. 

For the meaning of the other messages see figure 7f. The option of immediate distribution of the application- specific 
data by the BSC can be applied also in figure 7h, although it is not shown in the message flow (for details see figure If). 
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Figure 7i: After receiving application-specific data, a service subscriber in the anchor MSC area 
sends a confirmation for the received data to the other group call members, while the group call 

channel uplink in the cell is free. 

UPLINK_ACCESS (Establishment_cause=UL Request for sending application-specific data): This message is 
sent on the upHnk of the voice group call channel using random access procedures. The UPLINK_ACCESS message is 
similar to a channel request but sent on the group call channel uplink. 

VGCS_UPLINK_GRANT: The BSS grants the UpHnk of its group call channel immediately. The reply to the upHnk 
request sent on the voice group channel downlink containing information for synchronisation of the mobile station to 
the network and uplink access contention resolution. The VGCS_UPLINK_GRANT message shall therefore include a 
request reference (reflecting the UPLINK_ACCESS) and the physical information required for transmission on the 
voice group call channel uplink. 

SABM (DATAJNDICATION (Application_data)): The MS sends a SABM message with its mobile station identity 
and the Application_data to the BSS. For the purpose of identifying the received data, the data_id which was received in 
the message that contained the application data that is being confirmed shall be included in the message. 

For the meaning of the other messages see figure 7f. The option of immediate distribution of the application- specific 
data by the BSC can be applied also in figure 7i, although it is not shown in the message flow (for details see figure 7f). 
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Figure 7j: A listener in the anchor MSC area sends application-specific data that are not time-critical 
via RACH to the other group call members, while the talker is using the group call channel uplink in 

the same cell. 

RACH (CHAN_REQ): The network supports uplink access option (i) as defined in subclause 7.2, and the talker is on 
the group call channel in the same cell as the mobile station of the listener; therefore, the "uplink access indication for 
data" in the uplink busy message instructs the mobile station to use the RACH when application- specific data is to be 
sent. 

The mobile station leaves the group receive mode and sends the CHANNEL_REQUEST message with an appropriate 
establishment cause via the RACH to request an SDCCH. 

IMM_ASS: Standard message sent on the AGCH. 

SABM (DATA_INDICATION_2 (Application_data)): The MS sends a SABM message with its mobile station 
identity and the Application_data to the BSS on SDCCH. The network determines from the group call reference 
included in the message which group call is addressed by this message. 

UA (DATA_INDICATION_2 (Application_data)): This message is used to acknowledge the layer 2 link and provide 
contention resolution of the data indication 2. 

NOTE 1: Optionally, on receipt of the UA (DATA_INDICATI0N_2 (AppHcation_data) the mobile station 
performs a local release of the layer 2 link, i.e. without exchange of DISC/UA, and returns to group 
receive mode. 

NOTIFY_APPLICATION_DATA (Application_data): If the network option of immediate distribution of 
application-specific data by the BSC is activated, on receiving the application data sent from the MS, the BSS 
broadcasts the application data immediately to the cells within the BSC area in a notification message on the FACCH. 
Optionally, the NOTIFY_APPLICATION_DATA message for application-specific data is repeated on the group call 
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channel downlink. As a prerequisite for the immediate distribution, during the establishment phase of the voice group 
call the BSC stored the cell identities of the cells belonging to the group call area and served by the BSC. 

UPLINK_APPLICATION_DATA (CID, IDI, DATA_INDICATION_2): The BSS adds the sender's cell identifier 
(CID) and passes the L3 information (DATA_INDICATI0N_2) via the UPLINK_APPLICATION_DATA message to 
the MSC. If the BSC has immediately distributed the application data to its BSC area, the BSC shall additionally 
include the Immediate Distribution Indicator (IDI). 

CHANNEL_RELEASE: The BSS immediately releases the uplink by sending this message to the MS on the SDCCH 
including the channel description of the voice group call channel to which the mobile station shall tune to. The mobile 
station returns to group receive mode. 

NOTE 2: If the mobile station performed a local release of the layer 2 link, the following two messages will not be 
exchanged. Instead T3109 in the BSS will expire and the BSS will release the channel. 

DISC: Standard message to release the layer 2 link. 

UA: Standard message to acknowledge release of the layer 2 link. The mobile station returns to group receive mode. 

NOTIFICATION_DATA: The MSC sends NOTIFICATION_DATA messages with the appHcation data to all BSSs 
in their MSC area involved in the group call. If the originating BSC has immediately distributed the application data to 
its BSC area, the MSC shall not send the NOTIFICATION DATA message to the originating BSC. 

NOTIFY_APPLICATION_DATA (Application_data): The BSS broadcasts the appHcation data to all Hsteners and 
the talker, if any, in a notification message on the FACCH. Optionally the NOTIFY_APPLICATION_DATA message 
for application-specific data is repeated on the group call channel downlink. (The broadcast of the application data by 
the other BSSs is not shown in figure 7j.) 

For the meaning of the other messages see figure 7f. 

1 1 .3.9 Short Message Service (SMS) 

1 1 .3.9.1 Delivering SMS to the voice group call 

If the talking service subscriber, the listening service subscriber, the dispatcher in a voice group call, or any initiator of 
short messages who is not part of the voice group call wants to send a short message to the voice group call, it shall use 
the numbering scheme based on ITU-T Recommendation E.164 as the destination address illustrated below. 



cc 


NDC 


Prefix 


Group call reference 



The Country Code (CC) and National Destination Code (NDC) are used as normal for routing purposes. The CC and 
NDC may be omitted for internal SMS. The Subscriber Number (SN) is used to indicate: 

- the request of an SMS to a voice group call by use of a prefix. The length of the prefix shall be 1 to 2 digits. The 
value of the prefix shall be the same as the value used by a dispatcher when originating the voice group call (see 
subclause 9.2 d); 

- the wanted group call reference as defined in subclause 9.1. 

When receiving the short message, the SC may send Delivery Report message containing the received group call 
reference of the voice group to the sender of the short message, and furthermore the SC shall attempt to deliver the short 
message to the voice group call addressed by the group call reference. Figure 7f shows the MT SMS delivery procedure. 
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Figure 7f : Successful MT short message transfer attempt to a voice group call 

1) The SC sends a Message Transfer message to forward a short message to the SMS-GMSC. 

2) The SMS-GMSC sends the MT_ForwardSM_For_VGCS_REQ message to transfer the received short message 
to the A-MSC using the routing information derived from the group call reference. 

3) The A-MSC sends the GCR_SMS_Interrogation message to the GCR to retrieve the voice group call attributes 
for short message transfer. 

4) The GCR sends the GCR_SMS_Interrogation_Res message to the A-MSC containing the voice group call 
status and optionally the list of identities of dispatchers. 

5) The A-MSC sends the MT_ForwardSM_For_VGCS_RES message to the SMS-GMSC containing the status of 
the voice group call and optionally a list of identities of dispatchers if received from the GCR. Optionally, if the 
voice group call is currently ongoing, the SMS-GMSC may initiate point to point short message transfer 
attempts to the dispatchers of the voice group call. 

6) If the voice group call is established, the A-MSC sends the FORWARD_GROUP CALL_SIGNALLING 
message to deliver the short message to all related R-MSCs in the voice group call. 

7) If the voice group call is established, the A-MSC sends Message Transfer message to deliver the short message 
to the MSs participating in the voice group call within its MSC area. 
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8) If the voice group call is established, the R-MSCs sends Message Transfer message to deliver the short message 
to the MSs participating in the voice group call within its MSC area. 



1 1 .3.9.2 Point-to-point short message during an ongoing voice group call 

In this subclause the term point-to-point short message is used for mobile terminating short messages destined to a 
single subscriber and for mobile originating short messages, regardless whether their final destination is a single 
subscriber or a voice group call. 

For the transmission and reception of point-to-point short messages via CS domain during an ongoing voice group call, 
an MS and a network supporting this functionality shall apply the procedures specified in 3 GPP TS 23.040 [14] and 
3GPP TS 24.011 [15] as follows: 

a) When the talking service subscriber is on a dedicated channel, point-to-point short messages to be sent or 
received via the CS domain shall be transmitted on the S ACCH of the dedicated channel. If the talking service 
subscriber requests to release the uplink while a short message transfer is ongoing, the MS shall initiate the 
release of the uplink and abort the transfer of the short message. 

b) When the talking service subscriber is on a voice group call channel, the MS shall send mobile originating short 
messages via the CS domain on the S ACCH of the voice group call channel, if at least one of the following 
conditions is fulfilled: 

- the short message is destined to the ongoing voice group call of the talker; 

- the network broadcasts neither an SMS data confidentiality indication nor an SMS guaranteed privacy 
indication on the NCH; or 

- the network broadcasts an SMS data confidentiality indication, but no SMS guaranteed privacy indication on 
the NCH, and the voice group call channel is ciphered. 

Otherwise the MS shall leave the voice group call, send the short message as specified in 3GPP TS 24.011 [15] 
and return to the group call in group receive mode afterwards, if possible. 

If the talking service subscriber requests to release the uplink while a short message transfer on the voice group 
call channel is ongoing, the MS shall initiate the release of the uplink and abort the transfer of the short message. 

c) When the talking service subscriber is on a voice group call channel, the network may deliver mobile 
terminating point-to-point short messages via the CS domain on the S ACCH of the voice group call channel, if at 
least one of the following conditions is fulfilled: 

- the network does not broadcast an SMS data confidentiality indication on the NCH; or 

- the network broadcasts an SMS data confidentiality indication on the NCH, and the voice group call channel 
is ciphered. 

Otherwise the network shall perform paging into the ongoing voice group call as described in subclause 
11.3.1.3 c. The paging information on the FACCH of the voice group call channel shall indicate explicitly that 
the paging is for a short message. When the paging is received in group transmit mode, the reception of the 
paging shall be indicated to the subscriber. It is then up to the subscriber to respond to the paging or not. On 
request of the subscriber to respond to the paging, the MS in group transmit mode shall release the uplink, leave 
the voice group call, receive the short message as specified in 3GPP TS 24.011 [15], and return to the group call 
in group receive mode afterwards, if possible. 

If the talking service subscriber requests to release the uplink while a short message transfer on the voice group 
call channel is ongoing, the MS shall initiate the release of the uplink and abort the transfer of the short message. 

d) If an MS on a voice group call channel is not the endpoint of the layer 2 link for acknowledged message transfer, 
it shall ignore point-to-point short messages received on the S ACCH of the voice group call channel. 

e) On request of a listening service subscriber to send a point-to-point short message, the MS in group receive 
mode shall leave the voice group call, send the short message as specified in 3GPP TS 24.01 1 [15], and return to 
the group call in group receive mode afterwards, if possible. 
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For the delivery of a point-to-point short message to a Hstening service subscriber, the network shall peform 
paging into ongoing voice group calls by means of the notification procedure as described in subclause 11.3.1.3. 
The notification messages on the FACCH of the voice group call channel shall indicate explicitly that the paging 
is for a short message. When the paging is received in group receive mode, the reception of the paging shall be 
indicated to the subscriber. It is then up to the subscriber to respond to the paging or not. On request of the 
subscriber to respond to the paging, the MS in group receive mode shall leave the voice group call, receive the 
short message as specified in 3GPP TS 24.01 1 [15], and return to the group call in group receive mode 
afterwards, if possible. 

For the transmission and reception of point-to-point short messages via PS domain during an ongoing voice group call, 
class A mobile stations supporting this functionality shall apply the procedures specified in 3GPP TS 23.040 [14] and 
3GPPTS 24.011 [15]. 

Editor's note: For DTM mobile stations the transmission and reception of point-to-point short messages via PS 
domain during an ongoing voice group call is ffs. 

1 1 .4 Functional requirement of Anchor MSC 

The VGCS handling process in the anchor MSC is shown in figure 8. 

Successful call set-up 

When the VGCS handling process in the anchor MSC receives a VGCS call set-up request from either a dispatcher or a 
service subscriber currently located in the anchor MSCs area or a service subscriber currently located in a relay MSCs 
area, or - in a RANflex configuration - from a service subscriber currently registered in a VMSC, it interrogates its 
associated GCR to retrieve the group call attributes, and waits for a response. 

If the GCR returns a positive response containing the group call attributes, the anchor MSC 

sets up the downlinks to the cells inside the MSC area of the group call anchor MSC into which the call is to be 
sent.; If the "talker channel parameter" is used, the anchor MSC shall additionally send the parameter to the affected 
BSCs; 

sets up the connections to the dispatchers to which a dedicated link is to be established; 

sets up the connections to the relay MSCs into which the call is to be sent; 

starts the No Activity Timer; 

sends Forward Group Call Signalling messages containing the IMSI of the service subscriber who has initiated 
the call - if the call was not initiated by a dispatcher - to all relay MSCs (however not to the relay MSC from which 
the IMSI was received within the Send Group Call End Signal message if the call was initiated by a service 
subscriber located in the relay MSC area). In a RANflex configuration simultaneous group call setup of two service 
subscribers may result in two Send Group Call End Signal messages being received by the anchor MSC from two 
different relay MSCs, with both messages containing an IMSI. In this situation the anchor MSC shall discard the 
IMSI received from the relay MSC whose MSC address does not match the CLI from the lAM received and 
accepted from the originating MSC). If the network supports talker priorities, the anchor MSC includes the talker 
priority of the service subscriber who has initiated the call in the Forward Group Call Signalling messages; and 

waits for uplink management messages. 

Procedure Set-up Connections to Relay MSCs and BSCs 

The procedure is shown in figure 9. 

The procedure 

- sets up the downlinks to the cells inside the MSC area of the group call anchor MSC into which the call is to be 
sent. If the network supports talker priorities, the anchor MSC additionally sends the talker priority of the service 
subscriber who has initiated the call and, if applicable, the "emergency mode indication" with Uplink Seized 
Command messages" to the affected BSCs; 

sends PREPARE_GROUP_CALL messages to all relay MSCs and waits for the responses. If the "talker channel 
parameter" is used, the anchor MSC shall include this parameter in the PREPARE_GROUP_CALL messages. 
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If a positive response containing a Group Call number is received from a relay MSC, the anchor MSC constructs an 
lAM using the Group Call number as called party address, sends it to the relay MSC and waits for the SEND_GROUP 
CALL_END_SIGNAL message. 

If a SEND_GROUP_CALL_END_SIGNAL message without IMSI is received from a relay MSC, this indicates to the 
anchor MSC that at least one downlink to a cell has been successfully connected in the relay MSC area. 

If the call was originated by a service subscriber in a relay MSC area and a SEND_GROUP_CALL_END_SIGNAL 
message with the IMSI of the originator is received from this relay MSC, this indicates to the anchor MSC that the 
downlink to the originating cell has been successfully connected. If the negative response on the 
PREPARE_GROUP_CALL message is received from originating relay MSC, the call shall be released. 

Relay MSCs that do not send positive responses to the PREPARE_GROUP_CALL message are no longer considered to 
belong to the Hst of relay MSCs for this VGCS call. 

If, after receipt of a positive response containing a Group Call number from a relay MSC, the anchor MSC receives an 
ABORT from the relay MSC, the relay MSC will no longer be considered to belong to the list of relay MSCs for this 
VGCS call. 

Optionally in both cases the anchor MSC may retry to establish the connection to the relay MSC, instead of no longer 
considering the relay MSC to belong to the list of relay MSCs. 

If an ABORT message is received from the relay MSC the anchor MSC releases the connection, established with the 
Group Call number, to the relay MSC and the relay MSC is no longer considered to belong to the list of relay MSCs for 
this VGCS call. 

If a Release message for the connection established with the Group Call number is received from a relay MSC, then the 
anchor MSC sends an ABORT message to that relay MSC and the relay MSC is no longer considered to belong to the 
Hst of relay MSCs for this VGCS call. 

Unsuccessful call set-up 

If the call set-up is unsuccessful (i.e. conditions for call establishment have not been met as per subclause 11.3.1.1.2) 
the anchor MSC sends a SEND_GROUP_CALL_END_SIGNAL_ACK message or ABORT (depending on the state of 
the MAP dialogue) to all relay MSCs, releases the connections to the relay MSCs, releases all connections to 
dispatchers, all downlinks to cells inside the anchor MSC area are released, the GCR is informed that the call is no 
longer on-going and the process returns to the idle state. 

Negative response received from the GCR 

If the GCR returns a negative response to the anchor MSC indicating that the call is already on-going, the anchor MSC 
checks whether the call was initiated by a dispatcher. If so, the dispatcher is connected to the on-going call and the 
process returns to the idle state. If the call was initiated by a service subscriber, a Release message indicating "user 
busy" is returned in order to force the mobile station of the service subscriber to look for notifications of the respective 
group ID on the NCH and join the group call. 

If the negative response from the GCR indicates any other reason than "on-going call" the VGCS call set-up request is 
rejected by sending a release message back to the initiator and the process returns to the idle state. 

Uplink management 

If an anchor MSC not supporting talker priorities receives an Uplink Release Indication message from a BSC, the 
anchor MSC marks the uplink as free, sends Forward Group Call Signalling messages indicating "uplink release 
indication" to all relay MSCs, sends Uplink Release command messages to all other BSCs, restarts the No Activity 
Timer and waits for further uplink management messages. 

If an anchor MSC supporting talker priorities receives an Uplink Release Indication message from a BSC, the anchor 
MSC compares the talker priority included in the Uplink Release Indication with the stored talker priority. If they are 
equal, the anchor MSC proceeds as specified above for the anchor MSC not supporting talker priorities; otherwise the 
anchor MSC discards the Uplink Release Indication. 

If the anchor MSC receives an Uplink Request message without talker priority or with talker priority "normal 
subscriber" from a BSC, it checks whether the uplink is marked as free. If so, an Uplink Request Acknowledge message 
is returned to the BSC, Forward Group Call Signalling messages indicating that the uplink is no longer free are sent to 
all relay MSCs, Uplink Seized Command messages are sent to all other BSCs, the uplink is marked busy and the 
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process waits for further uplink management messages. If the upHnk was not free when receiving the UpHnk Request 
message, the request is rejected. 

If an anchor MSC supporting talker priorities receives an Uplink Request message with a talker priority higher than 
"normal subscriber" from a BSC, and the uplink is free or it was seized by the current talker with a lower talker priority, 
the anchor MSC checks whether the subscriber has the subscription for the requested talker priority for this group ID. In 
a RANflex configuration this check may require retrieval of information from the visited MSCA^LR by means of the 
MAP service SEND_GROUP_CALL_INFO. If so, the anchor MSC: 

- stores the received data; 

- sends Forward Group Call Signalling messages indicating "uplink seized command" with the requested talker 
priority to the relay MSCs; 

- returns an Uplink Request Acknowledge message with the requested talker priority to the BSC which has 
requested the uplink; 

- sends Uplink Seized Command messages with the requested talker priority to all other BSCs; 

- releases the current talker by sending a Clear Command message, if the talker is on a dedicated channel and is 
located in the anchor MSC; 

- marks the uplink busy; and 

- waits for further uplink management messages. 
Additionally, 

- if the requested talker priority is "emergency subscriber", the anchor MSC sets the emergency mode and includes 
the "emergency mode indication" in the Uplink Request Acknowledge message and the Uplink Seized 
Command messages; furthermore the anchor MSC alerts all active dispatchers with an appropriate emergency 
indication (e.g. in-band tone or announcement); furthermore the anchor MSC alerts all inactive dispatchers by 
setting up dedicated connections with an appropriate emergency indication (e.g. special CLI prefix or postfix, 
and in-band tone or announcement) and connects the dispatchers to the voice group call. 

- if the anchor MSC supports the transmission of additional subscriber-related information, it interrogates the VLR 
to get the "additional information" assigned to the new talker. In a RANflex configuration this may require 
retrieval of information from the visited MSCA^LR by means of the MAP service 

SEND_GROUP_CALL_INFO. If "additional information" is available, the anchor MSC includes the "additional 
information" in the Forward Group Call Signalling messages indicating "uplink seized command" to all relay 
MSCs and sends VGCS Additional Info messages to all BSCs involved in the call and connected to the anchor 
MSC. Furthermore, the anchor MSC sends a VGCS Additional Info message on the dedicated connection to the 
BSC serving the current talker, before it releases the current talker. 

If an anchor MSC supporting talker priorities receives an Uplink Request message with a talker priority higher than 
"normal subscriber" from a BSC, and the uplink was seized by the current talker with the same or a higher talker 
priority, then the anchor MSC sends an Uplink Reject Command message with the current talker priority to the BSC. 

If the anchor MSC receives an Uplink Request Confirm message from a BSC, it stores the received data and waits for 
further uplink management messages. Additionally, if the anchor MSC supports the transmission of additional 
subscriber-related information, it interrogates the VLR to get the "additional information" assigned to the subscriber. In 
a RANflex configuration this interrogation may require retrieval of information from the visited MSCA^LR by means of 
the MAP service SEND_GROUP_CALL_INFO. If "additional information" is available, the relay MSC sends VGCS 
Additional Info messages to all BSCs involved in the call and connected to this relay MSC, and Forward Group Call 
Signalling messages with the additional info to all relay MSCs. 

If an anchor MSC supporting talker priorities receives an Emergency Reset Indication from a BSC and the subscription 
check is successful, the anchor MSC resets the emergency mode, sends Emergency Reset Command messages to all 
BSCs involved in the call and connected to the anchor MSC, and Forward Group Call Signalling messages indicating 
"emergency reset command" to all relay MSCs. If the talker priority at receipt of the Emergency Reset Indication is 
"emergency subscriber", then it is changed in the anchor MSC to "normal subscriber"; furthermore the anchor MSC 
alerts all active dispatchers with an appropriate emergency indication (e.g. in-band tone or announcement); furthermore 
the anchor MSC alerts all inactive dispatchers by setting up dedicated connections with an appropriate emergency 
indication (e.g. special CLI prefix or postfix, and in-band tone or announcement) and connects the dispatchers to the 
voice group call. 
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If an anchor MSC not supporting talker priorities receives a Process Group Call Signalling message indicating "uplink 
release indication" from a relay MSC , the anchor MSC marks the uplink as free, sends Forward Group Call Signalling 
messages indicating "uplink release indication" to all other relay MSCs, sends Uplink Release command messages to all 
BSCs, restarts the No Activity Timer and waits for further uplink management messages. If there is a dedicated 
connection for the talking service subscriber between the relay MSC and the anchor MSC, the anchor MSC shall release 
this connection with cause 'normal, unspecified'. 

If an anchor MSC supporting talker priorities receives a Process Group Call Signalling message indicating "uplink 
release indication" from a relay MSC, the anchor MSC compares the talker priority included in the Process Group Call 
Signalling message with the stored talker priority. If they are equal, the anchor MSC proceeds as specified above for the 
anchor MSC not supporting talker priorities; otherwise the anchor MSC discards the Process Group Call Signalling 
message. 

If the anchor MSC receives a Process Group Call Signalling message from a relay MSC indicating "uplink request" 
without talker priority or with talker priority "normal subscriber", it checks whether the uplink is marked as free. If so, a 
Forward Group Call Signalling message indicating "uplink request acknowledgement" is returned to the relay MSC, 
Forward Group Call Signalling messages indicating that the uplink is no longer free are sent to all other relay MSCs, 
Uplink Seized Command messages are sent to all BSCs, the uplink is marked busy and the process waits for further 
uplink management messages. If the uplink was not free when receiving the Process Group Call Signalling message 
(Uplink Request), the request is rejected. 

If an anchor MSC supporting talker priorities receives a Process Group Call Signalling message from a relay MSC 
indicating "uplink request" with a talker priority higher than "normal subscriber", and the uplink is free or it was seized 
by the current talker with a lower talker priority, then the anchor MSC: 

- returns a Forward Group Call Signalling message indicating "uplink request acknowledgement" with the 
requested talker priority to the relay MSC; 

- sends Forward Group Call Signalling messages indicating "uplink seized command" and the requested talker 
priority to all other relay MSCs; 

- sends Uplink Seized Command messages with the requested talker priority to all ESS s involved in the call; 

- releases the current talker by sending a Clear Command message, if the talker is on a dedicated channel and is 
located in the anchor MSC; 

- marks the uplink as busy; and 

- waits for further uplink management messages. 
Additionally, 

- if the requested talker priority in the Process Group Call Signalling message from the relay MSC is "emergency 
subscriber", the anchor MSC sets the emergency mode and includes the "emergency mode indication" in the 
Uplink Seized Command messages; furthermore the anchor MSC alerts all active dispatchers with an appropriate 
emergency indication (e.g. in-band tone or announcement); furthermore the anchor MSC alerts all inactive 
dispatchers by setting up dedicated connections with an appropriate emergency indication (e.g. special CLI 
prefix or postfix, and in-band tone or announcement) and connects the dispatchers to the voice group call. 

- if "additional information" about the new talker was included in the Process Group Call Signalling message from 
the relay MSC, the anchor MSC includes the "additional information" in the Forward Group Call Signalling 
messages indicating "uplink seized command" to all other relay MSCs and sends VGCS Additional Info 
messages to all BSCs involved in the call and connected to the anchor MSC. Furthermore, the anchor MSC 
sends a VGCS Additional Info message on the dedicated connection to the ESC serving the current talker, before 
it releases the current talker. 

If an anchor MSC supporting talker priorities receives a Process Group Call Signalling message from a relay MSC 
indicating "uplink request" with a talker priority higher than "normal subscriber", and the uplink was seized by the 
current talker with the same or a higher talker priority, then the anchor MSC returns a Forward Group Call Signalling 
message indicating "uplink reject command" with the current talker priority to the relay MSC. 

If the anchor MSC receives a Process Group Call Signalling message with "additional info" from a relay MSC, the 
anchor MSC sends VGCS Additional Info messages to all BSCs involved in the group call and connected to the anchor 
MSC, and Forward Group Call Signalling messages with "additional info" to all other relay MSCs. 
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If an anchor MSC supporting talker priorities receives a Process Group Call Signalling message with "emergency mode 
reset command" from a relay MSC, the anchor MSC resets the emergency mode, sends Forward Group Call Signalling 
messages with "emergency mode reset command" to all other relay MSCs, and sends Emergency Reset Command 
messages to all BSCs involved in the call and connected to the anchor MSC. If the talker priority at receipt of the 
"emergency mode reset command" is "emergency subscriber", then it is changed in the anchor MSC to "normal 
subscriber"; furthermore the anchor MSC alerts all active dispatchers with an appropriate emergency indication (e.g. in- 
band tone or announcement); furthermore the anchor MSC alerts all inactive dispatchers by setting up dedicated 
connections with an appropriate emergency indication (e.g. special CLI prefix or postfix, and in-band tone or 
announcement) and connects the dispatchers to the voice group call. 

If the anchor MSC receives an ABORT message from a relay MSC, the connection to the relay MSC is released and the 
relay MSC is no longer considered to be part of the call. 

Call release 

If the anchor MSC receives the specific DTMF message sequence or the specific DTMF tone sequence for call 
termination from an entitled dispatcher (see figures 7b to 7d) or a Termination Request message from the initiating 
service subscriber who currently has access to the uplink, it sends Send Group Call End Signal ACK messages to all 
relay MSCs, sends Release messages to all relay MSCs, sends Release messages to all dispatchers and BSCs, informs 
the GCR that the call is no longer on-going and the process returns to the idle state. If the group call termination is 
initiated by an entitled dispatcher, and there is a dedicated connection for the talking service subscriber between the 
anchor MSC and the relay MSC, the anchor MSC shall release this connection with cause 'normal call clearing'. 

If the anchor MSC receives a Process Group Call Signalling message from a relay MSC indicating "release group call" 
or an ISUP Release message from a relay MSC indicating "Normal call clearing" for the calling service subscriber's 
dedicated connection to the anchor MSC, then the anchor MSC sends Send Group Call End Signal ACK messages to all 
relay MSCs, sends Release messages to all relay MSCs, sends Release messages to all dispatchers and BSCs, informs 
the GCR that the call is no longer on-going and the process returns to the idle state. 

If the anchor MSC receives an ISUP Release message from a relay MSC with cause value other than "Normal call 
clearing" for the calling service subscribers dedicated connection to the anchor MSC, then the anchor MSC shall send 
Uplink Release Command messages to all BSCs and Forward Group Call Signalling messages with Uplink Release 
Indication parameter to all relay MSCs. 

If the no activity time in the anchor MSC expires, i.e. "no activity" (as specified in subclause 8.1.2.3) has been detected 
for the time specified in the GCR, the anchor MSC sends Send Group Call End Signal ACK messages to all relay 
MSCs, sends Release messages to all relay MSCs, sends Release messages to all dispatchers and BSCs, informs the 
GCR that the call is no longer on-going and the process returns to the idle state. 

SM MX delivery 

When the VGCS handling process in the A-MSC receives an MT_ForwardSM_for_VGCS_REQ message from a SMS- 
GMSC, the A-MSC shall interrogate the GCR to retrieve the group call attributes for short message transfer. The A- 
MSC shall deliver to the SMS-GMSC the status of the voice group call and optionally a list of identities of dispatchers 
within the MT_ForwardSM_for_VGCS_RES message. 

If the voice group call is established, the A-MSC shall distribute the short message TPDU to all connected relay MSCs 
using the FORWARD_GROUP CALL_SIGNALLING message and shall deliver the short message to the relevant cells 
using the already established downlink channel for the voice group call. 

If the voice group call is not established, the A-MSC shall discard the short message TPDU. 
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Figure 8: The VGCS handling process in the anchor MSC (sheet 1 of 5) 
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Figure 8: The VGCS handling process in the anchor MSC (sheet 2 of 5) 
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Figure 8: The VGCS handling process in the anchor MSC (sheet 3 of 5) 
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Figure 8: The VGCS handling process in the anchor MSC (sheet 4 of 5) 
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Figure 8: The VGCS handling process in the anchor MSC (sheet 5 of 5) 
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1 1 .5 Functional requirement of Relay MSC 

The VGCS handling process in the relay MSC is shown in figure 10. 

Successful call set-up initiated by a service subscriber 

When the VGCS handling process in the relay MSC receives a VGCS call set-up request from a service subscriber 
currently located in a relay MSCs area, it interrogates its associated GCR to retrieve the anchor MSC address and waits 
for a response. 

If the GCR returns a positive response containing the anchor MSC address, the relay MSC sets up a dedicated 
connection for the initiating service subscriber to the anchor MSC by constructing an lAM with CLI set to the address 
of this relay MSC, sending it to the anchor MSC, and waits for call release. 

Negative response received from the GCR 

If the GCR returns a negative response to the relay MSC indicating that the call is already on-going, the relay MSC 
sends a Release message indicating "user busy" to the service subscriber in order to force the mobile station of the 
service subscriber to look for notifications of the respective group ID on the NCH and join the group call. 

If the negative response from the GCR indicates any other reason than "on-going call" the VGCS call set-up request is 
rejected by sending a release message back to the initiator and the process returns to the idle state. 

Successful call set-up initiated by the anchor MSC 

When the VGCS handling process in the relay MSC receives a PREPARE_GROUP_CALL message from the anchor 
MSC, it interrogates its associated GCR to retrieve the list of cells inside the relay MSC area into which the call is to be 
sent. 

If the GCR returns a positive response, the relay MSC requests a Group Call number from its VLR. 

If the VLR returns a Group Call number, a PREPARE_GROUP CALL acknowledgement containing the Group Call 
number is returned to the anchor MSC and the relay MSC waits for the incoming call. 

If the incoming call identified by the Group Call number is received, the relay MSC releases the Group Call number and 
sets up the downlinks to the cells inside the relay MSC area into which the call is to be sent. 

If the "talker channel parameter" is used, the relay MSC shall additionally send the parameter to the affected BSCs 

If the network supports talker priorities and the group call was initiated by a service subscriber currently located in the 
relay MSCs area, then the relay MSC additionally sends the talker priority of the service subscriber who has initiated 
the call and, if applicable, the "emergency mode indication" with Uplink Seized Command messages to the affected 
BSCs. 

If the group call was initiated by a service subscriber currently located in the relay MSCs area, then the relay MSC shall 
send a SEND_GROUP_CALL_END_SIGNAL message, including the IMSI of the service subscriber, to the anchor 
MSC when the downlink has been set up successfully to the originating cell. Additionally, if the network supports talker 
priorities, the relay MSC includes the talker priority of the service subscriber in the 
SEND_GROUP_CALL_END_SIGNAL message. 

If the call was not originated by a service subscriber from the relay MSC area, the relay MSC shall send a 
SEND_GROUP_CALL_END_SIGNAL message without IMSI information element to the anchor MSC as soon as a 
downlink has been set up successfully to any cell. 

Then the relay MSC waits for uplink management messages. 

Negative response received from the GCR II 

If the GCR returns a negative response to the relay MSC, the relay MSC returns a PREPARE_GROUP_CALL negative 
response to the anchor MSC and returns to the idle state. 

No Group Call number received from VLR 

If the VLR could not allocate a Group Call number, the relay MSC returns a PREPARE_GROUP CALL_CALL 
negative response to the anchor MSC, informs the GCR that the call is no longer on-going and returns to the idle state. 
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Abort received from VLR 

If the VLR indicates that the Group Call number supervision timer has expired, the relay MSC sends an ABORT 
message to the anchor MSC, informs the GCR that the call is no longer on-going and returns to the idle state. 

Abort received from Anchor MSC 

If, after returning a PREP ARE_GROUP_C ALL acknowledgement containing the Group Call number, an ABORT is 
received from the anchor MSC the relay MSC releases the Group Call number, informs the GCR that the call is no 
longer on-going and returns to the idle state. 

Abort initiated by Relay MSC 

The relay MSC may Abort the dialogue by sending an ABORT message to the anchor MSC(e.g. if the relay MSC fails 
to establish any downlinks in its area). The relay MSC also releases any resources, informs the GCR that the call is no 
longer on-going and returns to the idle state. 

Unsuccessful call set-up 

Unsuccessful call set-up is determined in the anchor MSC (as per subclause 11.3.1.1.2). The relay MSC follows the 
procedures specified for "Abort received from Anchor MSC" and "Call release". 

Uplink management 

If a relay MSC not supporting talker priorities receives an Uplink Release Indication message from a BSC, the relay 
MSC marks the uplink as free, sends a Process Group Call Signalling message indicating "uplink release indication" to 
the anchor MSC, sends Uplink Release Command messages to all other BSCs, and waits for further uplink management 
messages. 

NOTE: If there is a dedicated connection for the talking service subscriber between the relay MSC and the anchor 
MSC, the anchor MSC will release this connection with cause 'normal, unspecified'. 

If a relay MSC supporting talker priorities receives an Uplink Release Indication message from a BSC, the relay MSC 
compares the talker priority included in the Uplink Release Indication with the stored talker priority. If they are equal, 
the relay MSC proceeds as specified above for the relay MSC not supporting talker priorities, except that it includes the 
talker priority in the Process Group Call Signalling message to the anchor MSC; otherwise the relay MSC discards the 
Uplink Release Indication. 

If the relay MSC receives an Uplink Request message without talker priority or with talker priority "normal subscriber" 
from a BSC, the relay MSC checks whether the uplink is marked as free. If so, a Process Group Call Signalling message 
indicating "uplink request" is sent to the anchor MSC, Uplink Seized Command messages are sent to all other BSCs, the 
uplink is marked busy and the process waits for further uplink management messages. If the uplink was not free when 
receiving the Uplink Request, the request is rejected. 

If a relay MSC supporting talker priorities receives an Uplink Request message with a talker priority higher than 
"normal subscriber" from a BSC and the uplink is free or it was seized by the current talker with a lower talker priority, 
the relay MSC checks whether the subscriber has the subscription for the requested talker priority for that group ID. In a 
RANflex configuration this check may require retrieval of information from the visited MSCA^LR by means of the 
MAP service SEND_GROUP_CALL_INFO. If so, the relay MSC: 

- stores the received data; 

- sends a Process Group Call Signalling message indicating "uplink request" and the requested talker priority to 
the anchor MSC; 

- sends Uplink Seized Command messages with the requested talker priority to all other BSCs involved in the call 
and connected to this relay MSC; 

- releases the current talker by sending a Clear Command message, if the talker is on a dedicated channel and is 
located in this relay MSC; 

- marks the uplink as busy; and 

- waits for further uplink management messages. 
Additionally, 
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- if the requested talker priority is "emergency subscriber", the relay MSC sets the emergency mode and includes 
the "emergency mode indication" in the Uplink Seized Command messages; 

- if the relay MSC supports the transmission of additional subscriber-related information, it interrogates the VLR 
to get the "additional information" assigned to the new talker. In a RANflex configuration this may require 
retrieval of information from the visited MSCA^LR by means of the MAP service 

SEND_GROUP_CALL_INFO. If "additional information" is available, the relay MSC includes the "additional 
information" in the Process Group Call Signalling message indicating "uplink request" to the anchor MSC. 

If a relay MSC supporting talker priorities receives an Uplink Request message with a talker priority higher than 
"normal subscriber" from a BSC, and the uplink was seized by the current talker with the same or a higher talker 
priority, then the relay MSC sends an Uplink Reject Command message with the current talker priority to the BSC. 

If the relay MSC receives an Uplink Request Confirm message from a BSC, it stores the data and waits for further 
uplink management messages. Additionally, if the relay MSC supports the transmission of additional subscriber-related 
information, it interrogates the VLR to get the "additional information" assigned to the subscriber. In a RANflex 
configuration this interrogation may require retrieval of information from the visited MSCA^LR by means of the MAP 
service SEND_GROUP_CALL_INFO. If "additional information" is available, the relay MSC sends VGCS Additional 
Info messages to all BSCs involved in the call and connected to this relay MSC, and a Forward Group Call Signalling 
message with the additional info to the anchor MSC. 

If a relay MSC supporting talker priorities receives an Emergency Reset Indication from a BSC and the subscription 
check is successful, the relay MSC sends a Progress Group Call Signalling message with "emergency mode reset 
command" to the anchor MSC and Emergency Reset Command messages to all BSCs involved in the call and 
connected to this relay MSC, and waits for further uplink management messages. If the talker priority at receipt of the 
Emergency Reset Indication is "emergency subscriber", then it is changed in the relay MSC to "normal subscriber". 

If the relay MSC receives a Forward Group Call Signalling message from a anchor MSC indicating "uplink release 
indication", it marks the uplink as free, sends Uplink Release command messages to all BSCs and waits for further 
uplink management messages. 

If the relay MSC receives a Forward Group Call Signalling message from a anchor MSC indicating "uplink seized 
command" with or without talker priority, then the relay MSC 

marks the uplink as busy, 

sends Uplink Seized Command messages with the requested talker priority to all BSCs involved in the call and 
connected to this relay MSC; 

- releases the current talker by sending a Clear Command message, if the talker is on a dedicated channel and is 
located in this relay MSC; and 

- waits for further uplink management messages. 
Additionally, 

- if the Forward Group Call Signalling message from the anchor MSC contained the talker priority "emergency 
subscriber", the relay MSC sets the emergency mode and includes the "emergency mode indication" in the 
Uplink Seized Command messages; 

- if "additional information" about the new talker was included in the Forward Group Call Signalling message 
from the anchor MSC, the relay MSC sends VGCS Additional Info messages to all BSCs involved in the call 
and connected to the relay MSC. Furthermore, the relay MSC sends a VGCS Additional Info message on the 
dedicated connection to the BSC serving the current talker, before it releases the current talker. 

If the relay MSC receives a Forward Group Call Signalling message with the "additional info", the relay MSC sends 
VGCS Additional Info message to all BSCs involved in the group call and connected to this relay MSC, and waits for 
further uplink management messages. 

If the relay MSC receives a Forward Group Call Signalling message from an anchor MSC indicating "uplink reject 
command" with or without talker priority, it returns an Uplink Reject message to the BSC which has requested the 
uplink and waits for further uplink management messages. If the "uplink reject command" included a talker priority, the 
relay MSC includes the talker priority in the Uplink Reject Command message 
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If the relay MSC receives a Forward Group Call Signalling message from an anchor MSC indicating "uplink request 
acknowledgement" with or without talker priority, then the relay MSC 

- returns an Uplink Request Acknowledge message with the requested talker priority to the BSC which has 
requested the uplink; 

- sets up a dedicated connection for the new talker to the anchor MSC (implementation option); 

- releases the current talker by sending a Clear Command message, if the talker is on a dedicated channel and is 
located in this relay MSC; and 

- waits for further uplink management messages. 

Additionally, 

if the requested talker priority is "emergency subscriber", the relay MSC includes the "emergency mode 
indication" in the Uplink Request Acknowledge messages; 

- if "additional information" about the new talker is available, the relay MSC sends VGCS Additional Info 
messages to all BSCs involved in the call and connected to the relay MSC. Furthermore, the relay MSC sends a 
VGCS Additional Info message on the dedicated connection to the BSC serving the current talker, before it 
releases the current talker. 

If a relay MSC supporting talker priorities receives a Forward Group Call Signalling message with "emergency mode 
reset command" from the anchor MSC, the relay MSC resets the emergency mode, sends Emergency Reset Command 
messages to all BSCs involved in the call and connected to this relay MSC, and waits for further uplink management 
messages. If the talker priority at receipt of the "emergency mode reset command" is "emergency subscriber", then it is 
changed in the relay MSC to "normal subscriber". 

If the relay MSC receives a Forward Group Call Signalling message from an anchor MSC indicating "uplink release 
command", it sends an Uplink Release Command message to the BSC which currently has access to the uplink and 
waits for further uplink management messages. 

If the relay MSC receives an ABORT message from a anchor MSC, it sends release messages to all BSCs, informs the 
GCR that the call is no longer on-going and the process returns to the idle state. 

Call release 

When receiving a release message, with cause 'normal call clearing' from the anchor MSC for the dedicated connection 
which was set-up for the initiating service subscriber located in the relay MSC area, the relay MSC releases the 
connection to the service subscriber and the process returns to the idle state. 

When the initiating service subscriber releases the call while a dedicated connection to the anchor MSC is established, 
the relay MSC sends a release message with cause 'normal call clearing' for the dedicated connection to the anchor 
MSC and the process returns to the idle state. 

When the initiating service subscriber releases the call, while on a group call channel or a dedicated connection to the 
relay MSC, the relay MSC sends a Process Group Call Signalling message to the anchor MSC indicating "release group 
call" and waits for the Release message and the Send Group Call End Signal Acknowledgement from the anchor MSC. 

When receiving a Send Group Call End Signal Acknowledgement or ABORT from the anchor MSC, or a release 
message for the connection that was set up using the Group Call number, the relay MSC releases all downlinks to cells 
inside the relay MSC area, informs the GCR that the call is no longer on-going and the process returns to the idle state. 

SM MX delivery 

When the VGCS handhng process in the R-MSC receives a FORWARD_GROUP CALL_SIGNALLING message 
containing a short message TPDU from the A-MSC, the R-MSC shall deliver the short message to the relevant cells 
using the already established downlink channel for the voice group call. 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 



128 



ETSI TS 143 068 V9.2.0 (2010-10) 



Process VGCS_Handling_Relay_MSC 

I N 

Uplink management \ 
in Relay MSC. HO cases^ 
not covered. 



Idle 



VGCS call 
>setup 




from service 
I subscriber 



^ to OCR 



positive 
response 



Set CLI to 

NDC plus 

prefix 



plus 

group call 
reference 



lAM 



dedicated connection 
I to anchor MSC 



Wait for 
release 



>REL 



REL 



Idle 



from Service 
I subscriber 



to anchor MSC 
I normal call clearing 



negative 
response 




REL 
(user busy) 



Idle 



REL 



REL 



REL 



from anchor MSC 
] normal call clearing 



to service 
] subscriber 



1(7) 



Prepare / 
Group Call^ 



OCR \ 

Interrogation/ 



Wait for 
CR responsi 



^ to OCR 



Figure 10: The VGCS handling process in the relay MSC (sheet 1 of 7) 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 



129 



ETSI TS 143 068 V9.2.0 (2010-10) 



Process VGCS_Handling_Relay_MSC 



2(7) 



Uplink management \ 
in Relay IVISC. HOcas^s 
not covered. 



[ Wait for ^ 
GCR response 




ntoGCR 



Prepare Release ^ 

Group Cal Group Call 

\ACK. number / 



Wait for 
Connection 



ntoVLR 



call released > n to GCR 



Idle 



Negative 
response 




Negative 
response 




Abort n from Anchor MSC 



[ Wait for \ 
GCR response 

V N J 



Abort n from Anchor MSC 



Wait for 

Group Call 

number 



Figure 10: The VGCS handling process in the relay MSC (sheet 2 of 7) 
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Figure 10: The VGCS handling process in the relay MSC (sheet 3 of 7) 
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Figure 10: The VGCS handling process in the relay MSC (sheet 4 of 7) 
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Figure 10: The VGCS handling process in the relay MSC (sheet 5 of 7) 
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Figure 10: The VGCS handling process in the relay MSC (sheet 6 of 7) 
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Figure 10: The VGCS handling process in the relay MSC (sheet 7 of 7) 
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1 1 .5A Functional requirement of group call serving MSC (within a 
RANflex pool) 

The process in the group call serving MSC is shown in figure lOAl. 

The group call serving MSC is either the anchor MSC or a relay MSC. 

Successful call set-up initiated by a service subscriber 

When receiving a SEND_GROUP_CALL_INFO interrogation request from a VMSC, the group call serving MSC 
interrogates its associated GCR to retrieve the Group Call Reference and the Anchor MSC address from the given cell 
Id / Group Id pair and return this information to the VMSC. The group call serving MSC shall temporarily store in its 
associated GCR the initiating subscriber's talker priority, his subscribed additional information and his IMSI as received 
in the interrogation request from the VMSC. The group call serving MSC shall then wait for the group call being set up: 
If the group call serving MSC is the anchor MSC, it waits for an I AM from the VMSC; if the group call serving MSC is 
a relay MSC, it waits for a PREPARE_GROUP_CALL from the anchor MSC. 
Waiting for the group call being set up shall be supervised by a timer T3. 

When receiving lAM from the visited MSC, timer T3 is stopped and processing continues in the process 
VGCS_Handling_Anchor_MSC after reception of the VGCS call setup request in Idle state. 

When receiving PREPARE_GROUP_CALL from the anchor MSC, timer T3 is stopped and processing continues in the 
process VGCS_Handling_Relay_MSC after reception of PREPARE GROUP CALL in Idle state. 

Unsuccessful call set-up 

If the group call reference could not be retrieved or the GCR returns a negative response indicating "on-going call" to 
the group call serving MSC, an error indication is returned to the VMSC and the process returns to the idle state. 

At timeout of timer T3 the temporarily stored initiating subscriber's talker priority, his subscribed additional information 
and his IMSI shall be deleted from the GCR. 
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Figure 10A1 : The VGCS handling process in the group call serving MSC (sheet 1 of 1) 

The procedure in the group call serving MSC to retrieve subscription information from the VMSC is shown in figure 
10A2. 
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Figure 10A2: The VGCS subscription info retrieval procedure in thie group caii serving MSC (slieet 1 
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1 1 .5B Functional requirement of VMSC (within a RANflex pool) 

The process in the visited MSC is shown in figure lOB. 
Successful call set-up initiated by a service subscriber 
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When the VGCS handUng process in the originating MSC receives a VGCS call set-up request from a service 
subscriber, the VMSC derives the address of the group call serving MSC from the requesting subscriber's current LAC. 
If the VMSC is the group call serving MSC of the requesting subscriber's current LAC, processing continues in the 
process VGCS_Handling_Anchor_MSC or VGCS_Handling_Relay_MSC after reception of the VGCS call setup 
request in Idle state. Otherwise, the visited MSC interrogates the group call serving MSC by means of the MAP service 
SEND_GROUP_CALL_INFO to retrieve the anchor MSC address and Group Call Reference and waits for a response. 

If the group call serving MSC returns a positive response containing the anchor MSC address and the anchor MSC is 
not the visited MSC, the originating MSC sets up a dedicated connection for the initiating service subscriber to the 
anchor MSC by constructing an lAM with CLI set to the address of the group call serving MSC, sending it to the anchor 
MSC, and waits for call release. If the VMSC is the anchor MSC, processing continues in the process 
VGCS_Handling_Anchor_MSC after reception of the VGCS call setup request in Idle state. 

Negative response received from the group call serving MSC 

If the group call serving MSC returns a negative response to the originating MSC indicating that the call is already on- 
going, the originating MSC sends a Release message indicating "user busy" to the service subscriber in order to force 
the mobile station of the service subscriber to look for notifications of the respective group ID on the NCH and join the 
group call. 

If the negative response from the group call serving MSC indicates any other reason than "on-going call" the VGCS call 
set-up request is rejected by sending a release message back to the initiator and the process returns to the idle state. 
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Figure 10B: Tlie VGCS liandling process in the VMSC (sheet 1 of 2) 
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Figure 10B: Tlie VGCS liandling process in the VMSC (sheet 2 of 2) 
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1 1 .6 Functional requirement of GCR 

The process in the GCR is shown in figure 1 1 . 

Service subscriber initiated call 

If the GCR receives an interrogation request for a call initiated by a service subscriber who is located in the MSC area 
of the associated MSC, the GCR calculates the group call reference from the Group ID and the originating cell ID. 

If the group call reference was successfully calculated, the GCR checks whether a VGCS call with that group call 
reference is already on-going. 

If the call is not marked as on-going, the GCR checks whether an anchor MSC address is stored in its group call 
reference record. If this is the case, a positive response including the anchor MSC address is returned to the MSC, the 
IMSI of the initiating service subscriber is stored in the GCR and the process returns to the idle state. If no anchor MSC 
address is stored (i.e. the associated MSC is anchor MSC with respect to this group call reference) the GCR marks its 
group call reference record with "on-going call" and returns a positive response including the group call attributes to the 
MSC and the process returns to the idle state. 

If the group call reference could not be successfully calculated from the Group ID and the originating cell ID, the GCR 
returns a negative response indicating "failure" to the MSC and the process returns to the idle state. 

If the call was marked as on-going, the GCR returns a negative response indicating "on-going call" to the MSC and the 
process returns to the idle state. 

lAM initiated call 

If the GCR receives an interrogation request for a call initiated by a dispatcher or by a service subscriber who is not 
located in the MSC area of the associated MSC, the GCR checks the CLI of the initiator against the list of identities of 
dispatchers which are allowed to initiate the voice group call and against the stored relay MSC addresses in order to 
determine whether the initiator is allowed to set-up the call. If the check is successful the GCR checks whether a VGCS 
call with the same group call reference is already on-going. 

If the call is not marked as on-going, the GCR marks its group call reference record with "on-going call" and returns a 
positive response including the group call attributes to the MSC and the process returns to the idle state. 

If the CLI check was not successful, the GCR returns a negative response indicating "failure" to the MSC and the 
process returns to the idle state. 

If the call was marked as on-going, the GCR returns a negative response indicating "on-going call" to the MSC and the 
process returns to the idle state. 

Anchor MSC triggered call 

If the GCR (associated to a relay MSC) receives an interrogation request for a call triggered by the anchor MSC, the 
GCR deletes the IMSI of the initiating service subscriber which is possibly stored in its record, marks its group call 
reference record with "on-going call", returns a positive response including the list of cells inside the MSC area of the 
requesting MSC in which the call is to be sent to the MSC and the process returns to the idle state. 

VMSC triggered call (in a RANflex configuration) 

If the GCR (associated to a group call serving MSC) receives an interrogation request for a call triggered by the VMSC, 
the GCR 

- calculates the group call reference from the Group ID and the originating cell ID ; 

- stores the IMSI, talker priority and additional information received with the request ; 

- marks its group call reference record with "on-going call"; and 

- returns a positive response including group call reference and , if the group call serving MSC is a relay MSC, the 
anchor MSC address. 

Call release 
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If the GCR receives a call released indication from the MSC, the "on-going call" indicator in the group call reference 
record is reset and the process returns to the idle state. 

SM MT delivery 

When receiving an interrogation request from the A-MSC, the GCR shall check if the voice group call is established or 
not and shall send a response containing the voice group call attributes for short message transfer to the A-MSC. 
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Figure 1 1 : The process in tlie GCR (sheet 1 of 2) 
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Figure 1 1 : The process in tlie GCR (slieet 2 of 2) 
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1 1 .7 Functional requirement of VLR 

The Group Call number allocation process in the VLR is shown in figure 12. 

Successful procedure 

When receiving a request from the relay MSC to allocate a Group Call number, the VLR checks if a Group Call number 
is available. If so it selects a Group Call number, marks the number as allocated, returns a positive response including 
the Group Call number to the MSC, starts a supervision timer and waits for removal of the Group Call number. If the 
VLR receives a request to release the Group Call number, the VLR marks the Group Call number as free and the 
process returns to the idle state. 

No Group Call number available 

If no Group Call number is available, the VLR returns a negative response indicating "no Group Call number available" 
to the MSC and the process returns to the idle state. 

Supervision timer expires 

If the supervision timer expires, the VLR indicates to the relay MSC that the dialogue has to be aborted. 
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Figure 12: The Group Call number allocation process in the VLR 
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1 1 .8 Functional requirement of SMS Gateway MSC 

SM MT delivery 

When receiving a short message TPDU from the SC, the SMS-GMSC shall inspect the parameters and identify the 
group call reference. 

NOTE: The SMS-GMSC may be identical to the MSC. 

If the parameters are incorrect then the SMS-GMSC shall return the appropriate error information to the SC in a failure 
report (see clauses 9 and 10 of 3GPP TS23.040 [14]). 

If no errors are found within the parameters the SMS-GMSC shall send the MT_ForwardSM_For_VGCS_REQ 
message to transfer the received short message to the A-MSC using the routing information derived from the group call 
reference. 

If the SMS-GMSC receives the MT_ForwardSM_For_VGCS_RES message indicating the voice group call is 
established and including a list of identities of dispatchers, it may optionally initiate point-to-point short message 
transfer attempts to the dispatchers who are connected to the voice group call. 

If the SMS-GMSC receives the MT_ForwardSM_For_VGCS_RES message indicating the voice group call is not 
established, it shall either 

i) discard the short message and return the appropriate error information to the SC, or 

ii) initiate point to point short message transfer attempts to the members of the group. 



ETSI 



3GPP TS 43.068 version 9.2.0 Release 9 



147 



ETSI TS 143 068 V9.2.0 (2010-10) 



NOTE: How the routing information of the voice group call subscribers for the point to point SMS transfer can be 
derived from the group call reference is out of scope of this specification and implementation dependent. 
This can be achieved e.g. by an internal or external database. 
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Figure 13: The process in tlie SMS-GMSC (sheet 1 of 1) 
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1 2 Content of messages 

This clause specifies the content of the following messages: 
On the B-interface (MSC-VLR): 

- Allocate Group Call Number; 

- Allocate Group Call Number ack; 

- Allocate Group Call Number negative response; 
Release Group Call Number; 

Send Group Call Info; 
Send Group Call Info ack; 
Send Group Call Info negative response. 
On the E-interface (MSC-MSC): 

- Prepare Group Call; 

- Prepare Group Call ack; 

- Prepare Group Call negative response; 

- Send Group Call End Signal; 

- Forward Group Call Signalling; 

- Process Group Call Signalling; 

- Send Group Call Info; 

- Send Group Call Info ack; 

- Send Group Call Info negative response. 
On the I-interface (MSC-GCR): 

- GCR Interrogation; 

- GCR Interrogation ack; 

- GCR Interrogation negative response; 

- Call Released. 

In the tables which follow, information elements are shown as mandatory (M), conditional (C) or optional (O). A 
mandatory information element shall always be present. A conditional information element shall be present if certain 
conditions are fulfilled; if those conditions are not fulfilled it shall be absent. An optional element may be present or 
absent, at the discretion of the application at the sending entity. 

1 2. 1 Messages on the B-interface (MSC-VLR) 
12.1.1 Allocate Group Call Number 

No information element is required. 
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12.1.2 Allocate Group Call Number ack 

The following information element is required. 



Information element name 


Required 


Description 


Group Call number 


M 


E.164 number required to route the call from the anchor 
MSC to the relay MSC 



12.1 .3 Allocate Group Call Number negative response 

The negative response information element can takes the following value: 
- No Group Call number available. 

12.1.4 Release Group Call Number 

The following information element is required. 



Information element name 


Required 


Description 


Group Call number 


M 


E.164 number required to route the call from the anchor 
MSC to the relay MSC 



12.1.5 Send Group Call Info 

The following information elements are required. 



Information element name 


Required 


Description 


TMSI 


M 


TMSI of the service subscriber for whom the request is 
sent 


Group ID 


M 


see clause 9. 


Teleservice 


M 


The teleservice Voice Group Call indicates that the 
request is for VGCS 



12.1.6 Send Group Call Info ack 

The following information elements are required. 



Information element name 


Required 


Description 


IMSI 


M 


IMSI of the service subscriber for whom the request is 
sent 


Additional info 


C 


Must be present if VGCS additional info is supported and 
additional info is assigned to the subscriber. 


Additional subscriptions 


C 


Must be present if privilegedUplinkRequest , 
emergencyUplinkRequest or emergencyReset is 
subscribed by the service subscriber for whom the 
message is sent 
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12.1 .7 Send Group Call Info negative response 

The negative response information element can take the following value: 
- group Id not subscribed; 
unknown subscriber. 



1 2.2 Messages on the E-interface (MSC-MSC) 
12.2.1 Prepare Group Call 

The following information elements are required. 



Information element name 


Required 


Description 


Teleservice 


M 


The teleservice Voice Group Call indicates that a VGCS 
call has to be prepared 


Group call reference 


M 


see clause 9 


Cipher Algorithm, Group Key and 
Number 


M 


Information on the cipher algorithm and group key to be 
used 


Priority 


C 


The default priority level must be present if eMLPP 
applies 


Codec Info 


M 


Information on the codecs allowed for the VGCS call 


Talker channel parameter 





Indicates whether the network shall always establish and 
maintain a dedicated channel for the talking service 
subscriber 


Uplink Reply Indicator 





Indicates that the uplink reply procedure is applicable for 
the voice group call. Must be present if the GCR provides 
the corresponding information. 



1 2.2.2 Prepare Group Call ack 

The following information element is required. 



Information element name 


Required 


Description 


Group Call number 


M 


E.164 number required to route the call from the anchor 
MSC to the relay MSC 



12.2.3 Prepare Group Call negative response 

The negative response information element can takes the following value: 
- No Group Call number available. 
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12.2.4 Send Group Call End Signal 

The following information element is required. 



Information element name 


Required 


Description 


IMSI 


C 


The IMSI of the service subscriber who has initiated the 
call. Must be present if the call was initiated by a service 
subscriber in the relay MSC area 


Talker priority 


C 


Must be present if the call was set up by a service 
subscriber in the relay MSC area with a talker priority 
higher than "normal subscriber" 


Additional info 


c 


Must be present if VGCS additional info is supported and 
additional info is assigned to the currently talking service 
subscriber in the relay MSC area. 
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12.2.5 Forward Group Call Signalling 

The following information elements are required. 



Information element name 


Required 


Description 


IMSI 


C 


IMSI of the service subscriber who has initiated the call. Must 
be present if the message is used to transfer the IMSI to the 
relay MSC 


Uplink Request 
Acknowledgement flag 


C 


Must be present if the message is used as positive 
acknowledgement of an uplink request 


Uplink Release Indication flag 


c 


Must be present if the message is used to indicate to the relay 
MSC that the uplink is no longer busy 


Uplink Reject Command flag 


c 


Must be present if the message is used as negative 
acknowledgement of an uplink request 


Uplink Seized Command flag 


c 


Must be present if the message is used to indicate to the relay 
MSC that the uplink has become busy 


Uplink Release Command flag 


c 


Must be present if the message is used to indicate to the relay 
MSC that the uplink which is currently under control of the 
relay MSC has to be released 


State Attributes 


c 


Must be present if the message is used to indicate to the relay 
MSC that the downlink for a talker served by the relay MSC 
has to be muted or unmuted. 


Talker priority 


c 


Must be present in the same message as the Uplink Request 
Acknowledgement flag or Uplink Seized Command flag and is 
set to the talker priority of the new talking service subscriber, if 
this talker priority is higher than "normal subscriber". 
Must be present in the same message as the Uplink Reject 
Command flag and is set to the talker priority of the currently 
talking service subscriber, if this talker priority is higher than 
"normal subscriber". 


Additional info 


c 


Must be present if VGCS additional info is supported and the 
message is used to transfer additional info assigned to the 
currently talking service subscriber to the relay MSC. 

Must be present in the same message as the Uplink Request 
Acknowledgement flag. Uplink Reject Command flag, or Uplink 
Seized Command flag, if a talker priority is included in the 
same message. 


Emergency Mode Reset 
Command flag 


c 


Must be present if the message is used to indicate to the relay 
MSC that the emergency mode indication shall no longer be 
signalled 


SMTPDU 


c 


The short message transfer protocol data unit received from 
the Service Centre. Must be present if the message is used to 
transfer the short message TPDU received from the SC. 


Notification Data 


c 


Must be present if the message is used to indicate to the relay 
MSC that application-specific data shall be distributed in its 
area 



12.2.6 Process Group Call Signalling 

The following information elements are required. 
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Information element name 


Required 


Description 


Uplink Request flag 


C 


Must be present if the message is used to request uplink 
control from the anchor MSC 


Uplink Release Indication flag 


C 


Must be present if the message is used to indicate to the 
anchor MSC that the uplink has become free 


Talker priority 


c 


Must be present in the same message as the Uplink Request 
flag or Uplink Release Indication flag and is set to the talker 
priority of the service subscriber requesting or releasing the 
uplink, if this talker priority is higher than "normal subscriber" 


Additional info 


c 


Must be present if VGCS additional info is supported and the 
message is used to transfer additional info assigned to the 
currently talking service subscriber to the anchor MSC. 

Must be present in the same message as the Uplink Request 
flag, if the flag applies to a subscriber with a talker priority 
higher than "normal subscriber" 


Emergency Mode Reset 
Command flag 


c 


Must be present if the message is used to indicate to the 
anchor MSC that the emergency mode indication shall no 
longer be signalled 


Release Group Call flag 


c 


Must be present if the message is used to indicate to the 
anchor MSC that the VGCS call shall be released 


Notification Data 


c 


Must be present if the message is used to indicate to the 
anchor MSC that application-specific data shall be distributed 



1 2.2.7 MT Forward Short Message for VGCS Request 



The following information elements are required. 



Information element name 


Required 


Description 


Group call reference 


M 


see clause 9 


SM Originating Address 


M 


The originating address used by the short message service 
relay sub-layer protocol. 


SMTPDU 


M 


The short message transfer protocol data unit received from 
the Service Centre. 



1 2.2.8 MT Forward Short Message for VGCS Response 



The following information elements are required. 



Information element name 


Required 


Description 


Status of the voice group call 


M 


Indicating whether the voice group call is established or not. 


Dispatcher List 





A list of dispatcher identities received from the GCR. 
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12.2.9 Send Group Call Info 

The following information elements are required. 



Information element name 


Required 


Description 


Teleservice 


M 


The teleservice Voice Group Call indicates that the 
request is for VGCS 


Requested Info 


M 


Indicates whether 

a) IMSI, Additional Info, and Additional Subscriptions or 
b)Anchor MSC Address and Group CallReference 
are requested 


TMSI 


C 


TMSI of the service subscriber for whom the request is 

sent. 

Shall be present if IMSI, Additional Info and Additional 

Subscriptions are requested. 


Group ID 


M 


see clause 9. 


Cell Id 


C 


Identification of the cell where the group call initiating 
service subscriber is located. 

Shall be present if Anchor MSC Address and Group Call 
Reference are requested 


IMSI 


C 


IMSI of the service subscriber for whom the request is 

sent. 

Shall be present if Anchor MSC Address and Group Call 

Reference are requested 


Additional info 


C 


Shall be present if subscribed and if Anchor MSC 
Address and Group Call Reference are requested 


Talker priority 


C 


Shall be present if Anchor MSC Address and Group Call 
Reference are requested and the talker priority is higher 
than "normal subscriber" 



12.2.10 Send Group Call Info ack 

The following information elements are required. 



Information element name 


Required 


Description 


IMSI 


C 


IMSI of the service subscriber for whom the request is 

sent. 

Shall be present if it was requested. 


Additional info 


C 


Shall be present if requested and VGCS additional info is 
supported and additional info is assigned to the 
subscriber. 


Additional subscriptions 


c 


Shall be present if requested and 
privilegedUplinkRequest , emergencyUplinkRequest or 
emergencyReset is subscribed by the service subscriber 
for whom the message is sent 


Anchor MSC Address 


c 


E.164 number required to route the call from the VMSC 
to the anchor MSC. Shall be present if requested 


Group call reference 


c 


see clause 9. Shall be present if requested. 
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12.2.1 1 Send Group Call Info negative response 

The negative response information element can take the following value: 

- group Id not subscribed; 
unknown subscriber; 

- ongoing call; 

- failure. 

1 2.3 Messages on the l-interface (MSC-GCR) 
12.3.1 GCR Interrogation 

The following information elements are required. 



Information element name 


Required 


Description 


Group call reference 


C 


see clause 9. Must be present if the VGCS call was 
initiated by a dispatcher or by a service subscriber in the 
relay MSC area and the receiving GCR is associated to the 
anchor MSC, or if the receiving GCR is associated to a 
relay MSC and the GCR interrogation was triggered by a 
Prepare Group Call message received from the anchor 
MSC. 


Group ID 


C 


see clause 9. Must be present if one of the following 
conditions is fulfilled: 

1) the MSC is the visited MSC of the service subscriber 
initiating the VGCS call, except if the MSC is a relay MSC 
and the GCR interrogation was triggered by a Prepare 
Group Call message received from the anchor MSC; 

2) the GCR interrogation was triggered by a Send Group 
Call Info message received from the VMSC. 


Originating Cell ID 


c 


see clause 9. Must be present if one of the following 
conditions is fulfilled: 

1) the MSC is the visited MSC of the service subscriber 
initiating the VGCS call, except if the MSC is a relay MSC 
and the GCR interrogation was triggered by a Prepare 
Group Call message received from the anchor MSC; 

2) the GCR interrogation was triggered by a Send Group 
Call Info message received from the VMSC. 


CLI 


c 


Calling Line Identity of the initiating dispatcher, or the relay 
MSC number in case of service subscriber originated 
VGCS call in the relay MSC, or in a RANflex configuration, 
if the relay MSC is different from the VMSC, the MSC 
number of the group call serving MSC of the service 
subscriber initiating the VGCS call. Must be present if the 
MSC is not the visited MSC of the service subscriber 
initiating the VGCS call. 


Relay MSC indicator 


M 


A flag indicating whether the GCR interrogation was 
triggered from a Prepare Group Call message received 
from the anchor MSC 


Group Call Serving MSC 
indicator 


C 


A flag indicating whether the GCR interrogation was 
triggered from a Send Group Call Info message received 
from the VMSC. May be set to "yes" in a RANflex 
configuration only. 


IMSI 


C 


IMSI of the service subscriber who has initiated the VGCS 
call. Must be present if the MSC is the visited MSC of the 
service subscriber initiating the VGCS call, or the GCR 
interrogation was triggered by a Send Group Call Info 
message received from the VMSC 


Talker priority 


C 


Talker priority of the service subscriber who has initiated 
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the VGCS call. Must be present if the MSC is the visited 
MSC of the service subscriber initiating the VGCS call, or 
the OCR interrogation was triggered by a Send Group Call 
Info message containing a talker priority received from the 
VMSC 


Additional info 


C 


Additional info of the service subscriber who has initiated 
the VGCS call. Must be present if the MSC is the visited 
MSC of the service subscriber initiating the VGCS call, or 
the GCR interrogation was triggered by a Send Group Call 
Info message containing additional info received from the 
VMSC 


Uplink Reply Indicator 





Indicates that the uplink reply procedure is applicable for 
the voice group call. Must be present if the MSC is the 
anchor MSC and the related flag exists and is set in the 
GCR 
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1 2.3.2 GCR Interrogation ack 

The following information elements are required. 



Information element name 


Required 


Description 


Group call reference 


C 


Must be present if the GCR receives an interrogation request 
containing a Group ID and an Originating Cell ID. 


Cell List 


C 


A list of cells inside the MSC area into which the call is to be 
sent. Must be present if a) no anchor MSC address is 
present in the group call reference record and the GCR 
interrogation was not triggered by a Send Group Call Info 
message, or b) the relay MSC indicator was set in the GCR 
Interrogation message 


Anchor MSC Address 


c 


E.164 number required to route the call from the relay MSC 
and in a RANflex configuration from the VMSC to the anchor 
MSC. Must be present if the anchor MSC Address is present 
in the group call reference record 


Relay MSC List 


c 


A list of relay MSCs into which the call is to be sent. Must be 
present if a relay MSC list is present in the group call 
reference record and the GCR interrogation was not 
triggered by a Send Group Call Info message 


Group Key and Number 


c 


Information on the cipher algorithm and the group key to be 
used. Must be present if Group Key and Number is present 
in the group call reference record and the GCR interrogation 
was not triggered by a Send Group Call Info message 


Codec Information 


c 


Information on the codecs allowed for the voice broadcast 
call. Must be present if Codec Info is present in the group call 
reference record and the GCR interrogation was not 
triggered by a Send Group Call Info message 


Establish to Dispatcher List 


c 


A list of identities of dispatchers to which a dedicated link is 
to be established. Must be present if included in the group 
call reference record. Note that the CLI possibly received 
with the GCR interrogation message must not be included 


Release from Dispatcher List 


c 


A list of identities of dispatchers which are allowed to 
terminate the voice group call. Must be present if included in 
the group call reference record and the GCR interrogation 
was not triggered by a Send Group Call Info message 


Priority 


c 


The default priority level related to the voice group call if 
eMLPP applies. Must be present if included in the group call 
reference record and the GCR interrogation was not 
triggered by a Send Group Call Info message 


IMS! 


c 


IMSI of the service subscriber who has initiated the VGCS 
call. Must be present if the Relay MSC Indicator was set in 
the GCR interrogation message and the IMSI is present in 
the group call reference record 


No Activity Time 


c 


The length of the time over which no activity is detected 
before the voice group call is automatically terminated 


Talker priority 


c 


Talker priority of the service subscriber who has initiated the 
VGCS call. Must be present if talker priority is present in the 
group call reference record 


Additional info 


c 


Additional Info of the service subscriber who has initiated the 
VGCS call. Must be present if additional info is present in the 
group call reference record 


Originating Cell ID 


c 


Must be present if originating cell id is present in the group 
call reference record 


Talker channel parameter 





Indicates whether the network shall always establish and 
maintain a dedicated channel for the talking service 
subscriber 



12.3.3 GCR interrogation negative response 

The negative response information element can takes the following value: 
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- on-going call; 

- failure. 

12.3.4 Call released 

The following information element is required. 



Information element name 


Required 


Description 


Group call reference 


M 


see clause 9 



12.3.5 GCR SMS Interrogation 

The following information element is required. 



Information element name 


Required 


Description 


Group call reference 


M 


see clause 9 



12.3.6 GCR SMS Interrogation Response 

The following information elements are required. 



Information element name 


Required 


Description 


Status of the voice group call 


M 


Indicating whether the voice group call is established or not. 


Dispatcher List 





A list of identities of dispatchers connected to an established 
voice group call. 



1 3 List of system parameters 
13.1 Timers 

13.1.1 Txx 

This is a supervision timer on the anchor MSC for the setup of the voice group call. It is started on receipt of a SETUP 
message from the calling subscriber when the calling subscriber is in the anchor MSC area and on receipt of an ISUP 
lAM from the relay MSC when the calling subscriber is in the relay MSC area. Refer to subclause 1 1.3.1.1.2 for 
procedures on expiry. 

The value of timer Txx is operator specific. 

13.1.2 T1 

In a network supporting talker priorities or uplink access option (i) as defined in subclause 7.2, the uplink busy message 
on the FACCH of the voice group call channel downlink is repeated by the BSS every Tl seconds (see subclause 
11.3.7.1). 

The value of timer Tl is operator specific. Its default value is 5 seconds. 
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13.1.3 T2 

In a network supporting the transmission of additional subscriber-related information, the additional info message on 
the SACCH of the voice group call channel downlink is repeated by the BSS every T2 seconds, until the current talker 
releases the uplink or is released by the network (see subclause 11.3.7.1). 

The value of timer T2 is operator specific. Its default value is 5 seconds. 

13.1.4 Tbb 

In a network supporting validation of Priority Uplink Requests, the timer Tbb supervises the broadcast of a new token 
(Y) after a valid Priority Uplink Request has been received. 

If a Priority Uplink Request is received, and the token matches the token in the BSS (X) then the request is accepted, 
token X is invalidated and Tbb is started. On Tbb expiry a new token (Y), and the priority of the accepted request, is 
sent in the uplink busy message on the FACCH of the voice group call channels. The Tbb timer should be set to a value 
that allows other service subscribers who sent a Priority Uplink Request with token X, at the same time as the one 
accepted by the network, to be back on the voice group call channel in order to receive the new token (Y). 

The default value for Tbb is 500ms.. 

13.1.5 Ttv 

In a network supporting validation of Priority Uplink Requests, the timer Ttv supervises an additional validity period 
for an unused token (A). When Tl (supervising the periodic uplink busy) expires a new token (B) is sent in the uplink 
busy message on the FACCH of the voice group call channels and timer Ttv is started. If a Priority Uplink Request is 
received before Ttv expires and the token matches either token in the BSS (A or B), the request is considered to be 
valid, both tokens (A and B) in the BSS are invalidated and Ttv is stopped. If Ttv expires (i.e. no valid Priority Uplink 
Request has been received within Ttv seconds) the unused token (A) is invalidated. 

The value of timer Ttv is operator specific. The value chosen should allow for the reception of requests from service 
subscribers who have left the group call channel before receipt of the UPLINK_BUSY with new token (B). Its default 
value is Is. 

13.1.6 Tast 

In a network supporting A-interface link sharing timer Tast shall be used to measure the duration between periodic 
reports from the BSC to the MSC of Group Call Area cells for which channels have been assigned or released, pre- 
empted or failed since the last periodic report. When timer Tast expires, if new cells in the Group Call Area have been 
established or existing ones have been released, pre-empted or failed, the MSC shall be informed of the changes (see 
subclause 7.1b). If no changes have occurred nothing shall be sent. Timer Tast shall be restarted to measure the period 
of time until the next report. The timer shall be stopped when the call is released. 

The value of timer Tast is operator specific. Its default value is 5 seconds. 

13.1.7 T3 

In a RANflex configuration the group call serving MSC when receiving Send Group Call Info from the VMSC shall 
supervise the setup of the group call by timer T3. T3 is started when a positive Send Group Call Info result is returned 
to the VMSC and it is stopped when the group call is set up. At timeout the temporarily stored transient data are deleted 
from the GCR. 

The value of timer T3 is operator specific. Its default value is 5 seconds. 
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NP-21 


NP-030409 


N1-031217 


43.068 


013 


1 


Rel-5 


F 


5.2.0 


5.3.0 


Correction to MS Late Entry 
description 


Sept 
2003 


NP-21 


NP-030410 


N1 -031 332 


43.068 


014 


2 


Rel-6 


F 


5.3.0 


6.0.0 


Dispatcher signalled 
mute/unmute of talkers 
downlink and correction and 
update of incorrect 
implementation of CR 03.68 
A022 


Sept 
2003 


NP-24 


NP-040203 


N1 -041 073 


43.068 


016 


1 


Rel-6 


F 


6.0.0 


6.1.0 


Correction of PCH re- 
organization notification 


June 
2004 


NP-25 


NP-040373 


N1 -041 527 


43.068 


019 


1 


Rel-6 


A 


6.1.0 


6.2.0 


Correction on notification for 
first talker of VGCS call 


Sept 
2004 


NP-25 


NP-040329 


N1 -041 547 


43.068 


020 


1 


Rel-6 


B 


6.1.0 


6.2.0 


Introduction of USIM based 
ciphering for VGCS 


Sept 
2004 


NP-26 


NP-040515 


N1 -042061 


43.068 


021 


1 


Rel-6 


C 


6.2.0 


6.3.0 


Addition of VGCS 
reconfiguration procedure 


Dec 
2004 


NP-26 


NP-040515 


N 1-042075 


43.068 


022 


2 


Rel-6 


F 


6.2.0 


6.3.0 


Group Call Reference handling 
by the MSC during VGCS call 
establishment 


Dec 
2004 


NP-26 


NP-040515 


N1 -041 768 


43.068 


023 




Rel-6 


D 


6.2.0 


6.3.0 


Notification Response 
procedure 


Dec 
2004 


NP-26 


NP-040515 


N1 -041 769 


43.068 


024 




Rel-6 


D 


6.2.0 


6.3.0 


Clarification on Immediate 
Setup procedure 


Dec 
2004 


NP-26 


NP-040515 


N1 -041 803 


43.068 


027 




Rel-6 


B 


6.2.0 


6.3.0 


USIM based ciphering on 
dedicated channels 


Dec 
2004 


NP-27 


NP-050067 


N 1-050043 


43.068 


031 




Rel-6 


A 


6.3.0 


6.4.0 


Correction of the conditions for 
establishment of a voice group 
call 


March 
2005 


NP-27 


NP-050076 


N1 -050281 


43.068 


036 


1 


Rel-6 


F 


6.3.0 


6.4.0 


EPRT Inter-PLMN Group Call 
notification for dispatchers 


March 
2005 


CP-28 


CP-050057 


CI -050469 


43.068 


041 




Rel-6 


A 


6.4.0 


6.5.0 


Correction on the use of 
calling subscriber and 
destination subscriber 


June 
2005 


CP-28 


CP-050073 


CI -050722 


43.068 


028 


3 


Rel-7 


B 


6.5.0 


7.0.0 


Support of talker priorities and 
talker identity presentation 


June 
2005 


CP-28 


CP-050073 


CI -050742 


43.068 


043 


2 


Rel-7 


B 


6.5.0 


7.0.0 


VGCS Broadcast Point in the 
BSS 


June 
2005 


CP-29 


CP-050361 


C1-051117 


43.068 


047 


1 


Rel-7 


A 


7.0.0 


7.1.0 


Error correction 


Sept 
2005 


CP-29 


CP-050361 


CI -050903 


43.068 


051 




Rel-7 


A 


7.0.0 


7.1.0 


Correction of USIM based 
ciphering on dedicated 
channels 


Sept 
2005 


CP-29 


CP-050365 


C1-051112 


43.068 


048 


2 


Rel-7 


B 


7.0.0 


7.1.0 


EFR for VGCS 


Sept 
2005 


CP-29 


CP-050365 


CI -050901 


43.068 


049 




Rel-7 


B 


7.0.0 


7.1.0 


Delivery of information about 
the subsequent talker to the 
previous talker 


Sept 
2005 


CP-29 


CP-050365 


C1-051118 


43.068 


054 


1 


Rel-7 


F 


7.0.0 


7.1.0 


Correction on the uplink 
transmission management 


Sept 
2005 


CP-29 


CP-050365 


CI -050945 


43.068 


055 




Rel-7 


F 


7.0.0 


7.1.0 


Enhancement on the 
dedicated channel Assignment 
procedure 


Sept 
2005 


CP-29 


CP-050365 


CI -051 120 


43.068 


058 


1 


Rel-7 


B 


7.0.0 


7.1.0 


Delivery of short message to 
voice group call 


Sept 
2005 


CP-30 


CP-050549 


CI -051 580 


43.068 


060 


1 


Rel-7 


B 


7.1.0 


7.2.0 


VGCS A-interface link sharing 


Dec 
2005 


CP-30 


CP-050549 


CI -051 583 


43.068 


063 


1 


Rel-7 


B 


7.1.0 


7.2.0 


AMR for VGCS 


Dec 
2005 


CP-30 


CP-050549 


CI -051 692 


43.068 


059 


2 


Rel-7 


B 


7.1.0 


7.2.0 


Talker priority: Priority Uplink 
Request validation mechanism 


Dec 
2005 


CP-30 


CP-050549 


CI -051 693 


43.068 


064 


3 


Rel-7 


B 


7.1.0 


7.2.0 


Point to point short message 


Dec 
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during an ongoing voice group 
call 


2005 


CP-30 


CP-050549 


CI -051 449 


43.068 


068 




Rel-7 


D 


7.1.0 


7.2.0 


Editorial corrections 


Dec 
2005 


CP-31 


CP-060123 


CI -060243 


43.068 


0069 


1 


Rel-7 


F 


7.2.0 


7.3.0 


Data confidentiality for p-t-p SMS 
in an active voice group call 


March 
2006 


CP-31 


CP-060122 


CI -060058 


43.068 


0070 




Rel-7 


B 


7.2.0 


7.3.0 


Clarification of prefix for an SMS 
to an active voice group call 


March 
2006 


CP-31 


CP-060122 


CI -0601 08 


43.068 


0071 


1 


Rel-7 


B 


7.2.0 


7.3.0 


Enhanced support of AMR for 
VGCS 


March 
2006 


CP-31 


CP-060113 


CI -060496 


43.068 


0073 


2 


Rel-7 


A 


7.2.0 


7.3.0 


Correction of muting/un-muting 
procedure 


March 
2006 


CP-31 


CP-060122 


CI -060242 


43.068 


0074 




Rel-7 


B 


7.2.0 


7.3.0 


Correction of the distribution of 
emergency indications 


March 
2006 


CP-31 


CP-060122 


CI -060545 


43.068 


0076 


1 


Rel-7 


C 


7.2.0 


7.3.0 


Modification of conditions for 
VGCS call establishment 


March 
2006 


CP-31 


CP-060122 


CI -060547 


43.068 


0078 


1 


Rel-7 


F 


7.2.0 


7.3.0 


Addition to group call SM 
procedures 


March 
2006 


CP-31 


CP-060122 


CI -060549 


43.068 


0080 


1 


Rel-7 


F 


7.2.0 


7.3.0 


EPRT - Corrections and 
clarifications to the procedures for 
releasing the calling service 
subscribers dedicated connection 
to the anchor MSC 


March 
2006 


CP-31 


CP-060122 


CI -060550 


43.068 


0081 


1 


Rel-7 


F 


7.2.0 


7.3.0 


EPRT - Correction/ clarification of 
voice group call termination 
procedures 


March 
2006 


CP-31 


CP-060122 


CI -060570 


43.068 


0082 


2 


Rel-7 


F 


7.2.0 


7.3.0 


Clarification of the no activity time 


March 
2006 


CP-31 


CP-060122 


CI -060566 


43.068 


0083 


2 


Rel-7 


B 


7.2.0 


7.3.0 


Indication of the channel to be 
used for uplink requests 


March 
2006 








43.068 






Rel-7 




7.3.0 


7.3.1 


SDL source files updated 


April 
2006 


CP-32 


CP-060273 


CI -061 101 


43.068 


0075 


2 


Rel-7 


B 


7.3.1 


7.4.0 


Addition of interoperability with 
RANflex 


June 
2006 


CP-32 


CP-060272 


CI -061 103 


43.068 


0084 


2 


Rel-7 


C 


7.3.1 


7.4.0 


Optimized delivery of the 
additional information 


June 
2006 


CP-32 


CP-060272 


CI -060728 


43.068 


0085 




Rel-7 


F 


7.3.1 


7.4.0 


EPRT: Add signalling flow for a 
dispatcher originated VGCS 


June 
2006 


CP-32 


CP-060272 


CI -061 100 


43.068 


0086 


1 


Rel-7 


F 


7.3.1 


7.4.0 


Group Call Re-establishment by 
the BSS 


June 
2006 


CP-32 


CP-060276 


CI -060982 


43.068 


0088 


1 


Rel-7 


F 


7.3.1 


7.4.0 


TC-RT Clarification on use of the 
Uplink Reply Procedure 


June 
2006 


CP-32 


CP-060272 


CI -060983 


43.068 


0089 


1 


Rel-7 


B 


7.3.1 


7.4.0 


Talker priority and A-interface link 
sharing interaction 


June 
2006 


CP-32 


CP-060276 


CI -060861 


43.068 


0094 




Rel-7 


F 


7.3.1 


7.4.0 


Correction of Figure 6 


June 
2006 


CP-32 


CP-060272 


CI -060862 


43.068 


0095 




Rel-7 


F 


7.3.1 


7.4.0 


Correction of Figure 6a 


June 
2006 


CP-33 


CP-060464 


CI -061 910 


43.068 


0097 




Rel-7 




7.4.0 


7.5.0 


Failure cases during VGCS call 
establishment 


Sept 
2006 


CP-33 


CP-060464 


CI -061 503 


43.068 


0098 




Rel-7 




7.4.0 


7.5.0 


Common AMR configurations for 
VGCS and VBS 


Sept 
2006 


CP-33 


CP-060464 


CI -061 81 9 


43.068 


0100 




Rel-7 




7.4.0 


7.5.0 


EVGCS-Remove the limitation of 
speech version in A interface 
sharing 


Sept 
2006 


CP-33 


CP-060464 


CI -061 556 


43.068 


0103 




Rel-7 




7.4.0 


7.5.0 


Indicate the originating relay MSC 
address to anchor MSC 


Sept 
2006 


CP-33 


CP-060464 


CI -061 908 


43.068 


0105 




Rel-7 




7.4.0 


7.5.0 


Extension of Group ID 


Sept 
2006 


CP-33 


CP-060464 


CI -061 91 6 


43.068 


0110 




Rel-7 




7.4.0 


7.5.0 


Correction for radio resource 
assignment 


Sept 
2006 


CP-33 


CP-060470 


CI -061 81 6 


43.068 


0096 




Rel-7 




7.4.0 


7.5.0 


Corrections to interoperability with 
RANflex 


Sept 
2006 


CP-34 


CP-060664 


CI -062423 


43.068 


0117 


1 


Rel-7 




7.5.0 


7.6.0 


Emergency set/reset alert to 
dispatchers 


Dec 
2006 


CP-34 


CP-060664 


CI -062420 


43.068 


0112 


2 


Rel-7 




7.5.0 


7.6.0 


Corrections to SMS procedures 
during ongoing voice group call 


Dec 
2006 


CP-34 


CP-060664 


CI -062424 


43.068 


0119 


1 


Rel-7 




7.5.0 


7.6.0 


Optimized channel allocation of 
the calling subscriber 


Dec 
2006 
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CP-34 


CP-060664 


CI -062422 


43.068 


0116 


1 


Rel-7 




7.5.0 


7.6.0 


Clarifications to the case when a 
group ID with 8 digits is used 


Dec 
2006 


CP-34 


CP-060665 


CI -0621 11 


43.068 


0114 




Rel-7 




7.5.0 


7.6.0 


Condition for the inclusion of 
parameters in the GCR 
interrogation message 


Dec 
2006 


CP-34 


CP-060665 


CI -0621 13 


43.068 


0115 


_ 


Rel-7 




7.5.0 


7.6.0 


Addition of Teleservice Code to 
SendGroupCalllnfo 


Dec 
2006 


CP-34 


CP-060672 


CI -062509 


43.068 


0118 


1 


Rel-8 




7.6.0 


8.0.0 


Introduction of sending 
application-specific data to group 
call members 


Dec 
2006 


CP-36 


CP-070371 


CI -070684 


43.068 


0133 




Rel-8 


A 


8.0.0 


8.1.0 


TCRT: Definition of BSSAP 
procedure for release of VGCS 
call controlling connections 


June 
2007 


CP-36 


CP-070376 


CI -070973 


43.068 


0132 


1 


Rel-8 


A 


8.0.0 


8.1.0 


TCRT: Silent (re-)joining dipatcher, 
immediately talking dispatcher 


June 
2007 


CP-36 


CP-070376 


CI -070975 


43.068 


0130 


2 


Rel-8 


A 


8.0.0 


8.1.0 


Retry of the VGCS Assignment 
procedure 


June 
2007 


CP-36 


CP-070387 


CI -070686 


43.068 


0135 


. 


Rel-8 


A 


8.0.0 


8.1.0 


Correction of condition for cell 
specific speech version 


June 
2007 


CP-36 


CP-070387 


CI -070685 


43.068 


0134 


. 


Rel-8 


A 


8.0.0 


8.1.0 


Alignment of SDLs with condition 
for successful call setup 


June 
2007 


CP-36 


CP-070394 


CI -071 380 


43.068 


0140 


3 


Rel-8 


B 


8.0.0 


8.1.0 


TCRT: Distribution of time-critical 
application data by BSC to its 
broadcast area 


June 
2007 


CP-36 


CP-070394 


CI -071 374 


43.068 


0138 


3 


Rel-8 


C 


8.0.0 


8.1.0 


Talker channel parameter 


June 
2007 


CP-36 


CP-070394 


CI -070755 


43.068 


0136 


_ 


Rel-8 


D 


8.0.0 


8.1.0 


Correction of place of message 
flows for EVA 


June 
2007 


CP-37 


CP-070602 


CI -0721 14 


43.068 


0142 


2 


Rel-8 


F 


8.1.0 


8.2.0 


Correction to the talker channel 
parameter 


Sept 
2007 


CP-37 


CP-070604 


CI -071 620 


43.068 


0141 




Rel-8 


F 


8.1.0 


8.2.0 


TCRT: Correction to process 
VGCS Handling Relay MSC 


Sept 
2007 


CP-38 


CP-070793 


CI -072829 


43.068 


0143 




Rel-8 


F 


8.2.0 


8.3.0 


TCRT: Removal of the support of 
long application-specific data 


Dec 
2007 


CP-38 


CP-070815 


CI -072830 


43.068 


0144 




Rel-8 


F 


8.2.0 


8.3.0 


TCRT: Paging for incoming p-t-p 
transaction to service subscriber in 
an ongoing group call 


Dec 
2007 


CP-39 


CP-080136 


CI -080453 


43.068 


0148 


1 


Rel-8 


C 


8.3.0 


8.4.0 


TCRT: Warning tone for call 
termination due to time out of 
voice inactivity time 


March 
2008 


CP-39 


CP-080129 


CI -080452 


43.068 


0147 


1 


Rel-8 


F 


8.3.0 


8.4.0 


TCRT: Clarification of the channel 
to be used for uplink access 


March 
2008 


CP-39 


CP-080123 


CI -080536 


43.068 


0146 


1 


Rel-8 


A 


8.3.0 


8.4.0 


TCRT: Clean up of the 
requirement of sending SMS to 
non established group calls 


March 
2008 


CP-40 


CP-080351 


CI -081 646 


43.068 


0149 




Rel-8 


B 


8.4.0 


8.5.0 


TCRT: Closing some open issues 
concerning the transmission of 
application-specific data 


June 
2008 


CP-40 


CP-080361 


CI -081 648 


43.068 


0150 




Rel-8 


F 


8.4.0 


8.5.0 


TCRT: Clarification of conditions 
for start and stop of voice inactivity 
timer 


June 
2008 


CP-46 












Rel-9 




8.5.0 


9.0.0 


Upgrade to Rel-9 


Dec 
2009 


CP-47 


CP-100135 


CI -100476 


43.068 


0151 




Rel-9 


C 


9.0.0 


9.1.0 


TCRT: Uplink reply procedure 


March 
2010 


CP-49 


CP-1 00501 


CI -10231 6 


43.068 


0152 




Rel-9 


F 


9.1.0 


9.2.0 


TC-RT: Use of application data for 
group calls involving more than 
one PLMN 


Septem 

ber 

2010 
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